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FOREWORD 


This is a collection of technical papers presented at the 
first four ARRL Amateur Radio Computer Networking Conventions, 
They span the period 1981 through 1985, which were the formative 
years of amateur packet-radio development. These papers include 
a wide range of subjects. Some are theoretical; others cover 
practical applications. There is extensive treatment of 
protocols, software and hardware subjects. 


The year 1984 sawthecompletion of the AX.25 Amateur 
Packet-Radio Link-Layer Protocol by the ARRL Ad Hoc Committee on 
Amateur Radio Digital Communication in September, and approval of 
the protocol by the ARRL Board of Directors in October. 


All papers contained in this publication are unedited and 
are solely the responsibility of the authors. 


David Sumner, K12ZZ 
Executive Vice President 


Newington, Connecticut 
september 1985 
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Introduction 


The American Radio Relay League (ARRL) is 
sponsoring this first international Amateur 
Radio Computer Networking Conference for se- 
veral reasons. One is to recognize the in- 
novative work that Canadian and U.S. ama- 
teurs have already done in packet radio. 
Another is to explore the possibilities of 
an integrated amateur packet network. As- 
suming that there is a consensus that a net- 
work can be developed, the third is to try 
to set up a framework for orderly growth. 


This paper outlines my current thinking 
on some aspects of amateur packet radio net- 
working. I have included a number of things 
that I believe should be considered at this 
conference and in the few months ahead. 


Organization 


In the past year, there has developed an 
informal group of packet radio leaders from 
different clubs. Fortunately, these indi- 
viduals have been both advocates and doers. 
They have been in frequent touch with each 
other using various means of communication 
such as amateur radio, personal meetings, 
the mails and other methods. I 'm speaking 
mainly of: 


Hamilton, ON 
Sterling, VA 
Ottawa, ON 
Vancouver, BC 
San Francisco, CA 


Stu Beal, VE3MWM 
Dave Borden, K8MMO 
Larry Kayser; VE3QB 
eae Lockhart, VE7AFPU 
Hank Magnuski, KA6M 


I would also like to be counted in this 
roup. I'm sorry if I left anyone out who 
eels that he/she should have been included. 
The above list is meant to include the per- 
sons acting as gateways between their clubs 
and most of the others. 


So far, this informal group has managed 
get the word around on new developments and 
has been able to move things along. 


In any new enterprise, there is a tenden- 
cy for someone to propose that the informal 
organization be replaced by a formal one. 

It is my feeling that this is a highly ex- 
perimental and dynamic endeavor aud that we 
shouldn’t fix what ' s working. 


Therefore, I suggest that we give at 
least tacit approval to this informal group 
and give them the ball on deciding when this 
leadership function needs to be formalized. 


Our organizational energies should be fo- 
cused, for the moment, on supporting the ex- 
isting organizations. As an individual, you 
should see to it that your club attracts new 
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members and helps them get on the air with 
ackets. Virtually a.11 the clubs are gross- 
y underfunded and could use help raising 
money, The club newsletters need more ¢ca- 
Pao writers on a variety of packet topics,, 
n addition, writers need’to send top quali- 
ty packet tutorials and technical articles 
to the ARRL publications gst and geEx. 


Network Management Issues 


Network architecture (structure, hierar- 
chy, protocol, routing strategies) needs to 
be ironed out soon. The Network Architec- 
ture Seminar of this conference should help 
to move this subject along toward some type 
of agreement. I personally favor a two-tier 
system. At the lower level, there would be 
Local Area Networks (each with their own re- 
pea ter), designed to fit the needs of the 
area. At the higher level, we would have 
a larger network (sometimes called an inter- 
net) Which uses commonly agreed rules and 
can pass traffic via hf, satellite and ter- 
restrial circuits. Aliso, I feel it essen- 
tial to the network’s growth that a new sta- 
tion (terminal or network node) be able to 
fire up without begging someone’s permis- 
sion. 


Financing the network needs some fresh 
thinking. ndoubtedly, the local area net- 
works will be financed locally as are the 
numerous Z-meter fm repeaters. However, the 
internet needs both local an.d network-wide 
financing. The latter category may include 
a number of the following possibilities: 


eA network membership (users and sup- 
porters) fee on the order of $25 or more a 
year. 


eA fund such as the ARRL Foundation to 
appeal to all radio and computer amateurs. 


eProposals for seed money to government 
and/or industry. There is a. joint AMRAD/ 
ARRL proposal calling for funding of 8 hf 
packet stations in its early stages of con- 
sideration by the U.S. Government. 


Applications of the network need to be 
thrashed out, The Applications Seminar of 
this conference should stimulate some new 
thought. For one thing, ] think that the 
network should develop a capability of 
handling third-party traffic. Serious con- 
sideration should be given to handling tele- 
typewriter (TTY) traffic for the deaf. 
Barry Strassler will present a paper on this 
subject. I believe that handling of deaf 
TTY traffic is feasible via a special type 
of computerized bulletin board (CBBS) de- 
veloped by AMRAD called HEX (Handicapped 
Educational Exchange) which speaks both 


ASCII and Baudot/Murray codes. In fact, we 
need to talk about the possibilility of 
interconnecting with all CBBS's in North 
America. This carries with it the problems 
of getting the individualistic system 
operators to understand the need to comply 
with the internet standards, Perhaps the 
knottier problem is how to screen all traf- 
fic to eliminate commercial and other no-no 
traffic before it is transmitted over Ama- 
teur Radio. 


Acronvmics 


Acronymics is a made-up word meaning 
playing around with acronyms. We need some 
agreed names to call things within the net- 
work. I was recently advised to leave this 
subject to discussion over beer and pizza. 
Ignoring that, here goes. 


First, I propose that the overall net- 
work be called AMNET. The term should spe- 
cifically apply to the internet and general- 
ly to the various Local Area Networks (LANs) 
connected to it. AMNET is meant to be an 
umbrella term. 


The internet will be made up of three 
transmission (sometimes called transport) 
systems, as outlined below: 


@® Thesatellite net, fortunately, has 
already been given an acronym: AM , 
standing for AMSAT International COmputer 
Network. In the interest of symmetry, maybe 
we should make the other transmission sys- 
tem acronyms end in CON. 


eThe net of vhf/uhf packet repeaters 
along the countryside or terrain could be 
called TERRACON. 


*The high-frequency net uses the ion- 
sphere to skip long distances, so why not 
dub this SKIPCON? 


It would seem natural to follow commer- 
cial practice and call the stations that 
change from one net or medium to another 
gateways. I'm proposing to call these gate- 
ways: SKYGATE for satellite gateways, 
TERRAGATE for vhf/uhf gateways, and SKIPGATE 
for hf gateways. The need for SKYGATEs and 
SKIPGATEs is fairly obvious. But there 
could be TERRAGATEs too where there is need 
to change frequencies, data rates and per- 
haps protocols. 


I suggest that we leave the naming of the 
LANs to the local sponsors. It may also be 
necessary to name some virtual networks that 
people cook up within the network. Eventu- 
ally, I'd like to see all these names (fre- 
quencies and other parameters) published in 
a directory by the ARRL. The time will come 
quite soon when we will need a packet radio 
directory which lists all network facilities 
as well as individual packet radio stations. 
To kick this off, AMRAD is offering to col- 
lect the information and organize it in a 
directory form. We already have a CBBS Di- 
recto... “hich could be included. 


1.2 


Internet Standards 


If the internet is to work it must have 
agreed standards. There must be agreement 
on a wide set of particulars including pro- 
tocols, routing strategies, radio frequen- 
cies, etc. Yet we need to temper this with 
maximum flexibility. There are a number of 
fundamental issues to be addressed. For 
example, do we want to look for government 
seed money and configure the network so that 
it can handle government traffic in emergen- 
cies; e.g., use ARPA's Internet protocol? 
Perhaps the other issues can be better 
handled according to the medium used: 


Vhf/uhf Terrestrial Net Standards 


This net should consist of a number of 
single-frequency vhf/uhf repeaters, each 
with a capability of working neighboring re- 
peaters on the same frequency. This can go 
on for an unlimited number of hops, or the 
chain can be broken by changing to another 
frequency. Propagationally, the 144, 220 or 
420 MHz amateur bands would be acceptable. 

I am inclined to push the 220-MHz band be- 
Cause it is underutilized, Influencing the 
choice of frequencies may be the signaling 
speed permitted by the Federal Communica- 
tions Commission in the U.S. Current Rules 
permit only 1200 baud at 144 and 220 MHz and 
19.6 kilobaud at 420 MHz. 


What speeds should we use? In packet 
communications it is necessary to have a 
high enough signaling speed to handle the 
volume of traffic without the network going 
critical and being tied up permanently with 
retries. That says, "the higher speed the 
better." But, raising speed means increas- 
ing bandwidth (all other things equal) which 
means higher transmitter power for an accept- 
able signal-to-noise ratio. Certainly, 1200 
baud is not sufficient for such a net. 

2400 and 4800 baud are not that much better. 
9600 becomes marginally usable. From here, 
the American National Standards Institute 
(ANSI X3.36-1975) pegs the standard speeds 
at integral multiples of 8000 bits per se- 
cond, so the next speeds are: 16, 24, 32, 
40, 48, 56 kilobits, etc. ANSI shows 16 and 
56 as “selected standard signaling rates" 
and recognizes 48 kilobits per second as a 
recognized standard for international trans- 
mission. Thus, it looks like the choice for 
the high end is either 48 or 56 kb/s. The 
low-end choice seems to be 16 kb/s. I was 
pushing 48 kb/s because of its international 
blessing by the CCITT, but I have learned 
that very few circuits have been implemented 
at that speed and that modems are extremely 
rare/expensive. I suggest that we look very 
closely at 56 kb/s as a proposed standard. 
That still gives us a modem problem to be 
solved by amateur ingenuity. 


If we want to operate such speeds at 
220 MHz, we will need to petition the FCC 
for a Rules change. Probably the best ap- 
proach is to request a Special Temporary Au- 
thority (STA) as a first step. I believe 
that we want to ask for permission to use 


up to 56 kb/s in a portion of the 220-MHz 
band. You may have noted that the Canadians 
already have Department of Communications 
permission to use various bandwidths up to 
100 kHz in the 220-MHz band. Unfortunately, 
there is no simple method cf equating band- 
width to signaling speed because things 
change with different modulation schemes. 
There has been a tendency for hams to think 
of fsk for transmission of data because we 
are used to sending RTTY that way. The pro- 
blem is that fsk gobbles up too much band- 
width. Phase-shift keying (psk) conserves 
bandwidth, particularly if we can use 
quadraphase psk. There is much work to do 
on designing practical modems for these data 
rates. Commercial (say 56 kb/s) modems are 
far outside our price range. I'd like to 
see someone Ide into the design feasibility 
of a qpsk modem operating at a 10.7-MHz car- 
rier frequency for the internet repeaters. 


As for where in the 220-MEz band we 
should put these repeaters, I circulated an 
informal letter on this subject in May of 
this year. If you wish to research this 
problem, you should look at the Canadian 
Amateur Bands, !*2 U.S. Amateur Radio Fre- 

uency Allocations,? and the ARRL Vhf-Uhf 
Advisory Committee 220-225-MHz band plan.* 
Study of these references reveals that the 
220.0-220.5 subband is not usable because 
FCC rules do not permit repeaters. The FCC 
permits repeaters above 220.5 MHz. Starting 
at 221.9 MHz there is a weak-signal guard 
band, EME (moonbounce), propagational bea- 
cons, weak-signal cw, calling frequency, 
eneral operations (cw/ssb), as well as 

m repeaters and simplex channels to use 
up the higher part of the band, as out- 
lined in the band plan. So, that narrows 
packet repeater operation down to the sub- 
band 220.5 to.221.9 MHz in the U.S. This 
applies only to the internet repeaters or 
possibly local area net repeaters which use 
data rates above 1200 baud (with FCC STA or 
rules change, of course). Local repeaters 
using 1200 baud could operate on fm voice 
repeater or simplex frequencies in the 144, 
220 or 440-MHz bands. 


The proposed 220. 5-221.9-MHz internet 
packet repeater subband needs to be broken 
down into channels. MHere’s my first cut; 
I'd welcome some comments: 


a. Channelize on 100-kHz inter- 
vals, e.g., 220.6, 220.7, etc. This will 
allow us to run up to 100 kHz bandwidth per 
channel. It will probably be necessary to 
keep two channels operating in the same 
area at least 400 kHz apart. Packet re- 
ceivers may use fm broadcast 10.7-MHz i-f 
transformers because of their low cost. 
Although fm broadcast band channel spacing 
is every 200 kHz, it is not usual to have 
adjacent channels allocated in the same 
area. 


b. As the arguments over whether 
to use simplex or duplex packet repeaters 
are not over, it might be prudent to look at 
the possibility of designating some duplex 
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channels within the 220. S-221. 9-MHz subband,, 
If the duplexer possibilities permit this, 
it would seem logical to have several duplex 
channels with inputs at one end and outputs 
at the other end of the subband. Then, the 
simplex packet channels could go in the 
middle: 
Frequencies Proposed Use 
220 36/2246 
L207 I 220.7 
220,8/221.8 " 


220.9 
221.0 
221.1 " 
221.2 " 
221.3 " 
221.4 " 
221.5 " 


Packet repeater pair 
Al 


Packet repeater simplex 
" 


There is an immediate need for a group 
of people to work o:n terrestrial vhf/uhf re- 
peater standards and hardware design. Be- 
cause of the scarcity of commercial 220-MHz 
equipment with up to 100 kHz bandwidths and 
quick turn-around time, it appears that most 
220-MHz packet repeaters will be homebrewed. 
Doug Lockhart, VE7APU has circulated an in- 
formal paper which proposes certain design 
criteria. His basic idea is to come up with 
a single-board repeater that can be easily 
replicated across the continent. We need 
someone to undertake this design effort on 
a priority basis. 


AMICON Standards 


The focus of this work has been on the 
use of the data communications special ser- 
vice channel (L2) on the AMSAT Phase III 
satellite. There is already a committee in 
lace headed by Hank Magnuski, KA6M. They 
ave already drafted several generations of 
AMICON specifications which have been cir- 
culated to those directly involved. 


Hf Standards 


My concept is to have at least 8 hf 
gateways in the U.S., and about 6 in Canada. 
Within the bounds of ionospheric propaga- 
tion, all should be able to talk directly 
to each other. If not, some can relay. 


I would like to see the hf net run 
automatically, without human operators in- 
volved in sending and receiving packets. 
Computer control and digitally controllable 
rigs such as the ICOM IC-701/720 and the 
Collins KWM-380 permit this. A signal plan 
in software would provide the time slots 
with frequencies, antenna orientations and 
other information required for communica- 
tions between the then-active stations. 


Now, on to hf signaling speeds. Here 
is an area where we will. have to do some 
experimentation. The enemy is multipath. 

If you could always operate at the maximum 
usable frequency (muf) for the path, you 
could send at almost any speed because there 


would be only one path through the ionospher- 
ic layer. On the ham bands, it is not at all 
certain that you will be operating at or near 
the muf. Presently, the hf bands are alloca- 
ted every octave, the exception being the 21- 
MHz band which falls between the 14- and 28- 
MHz bands. The addition of the new WARC 
bands at 10 and 18 MHz will help this situa- 
tion for the longer paths. There remains an 
octave gap between the 3.5- and 7-MHz bands 
which will make it difficult for the shorter 
hf paths where multipath is a limiting fac- 
tor. (It would be nice to have a frequency 
near 5 MHz that could be used by hams for 
packet operations.) 


The worst-case situation on hf 
for multipath is in the vicinity of 100 km 
(near- -vertical-incidence paths). Here, the 
maximum expected delay difference at fre- 
quencies below the muf could be about 8.5 ms, 
according to Salaman _work on Multipath Reduc- 
tion Factor (MRF). 


MRF or delay difference is manifested 
by a new bit and old bit overlapping each 
other. The question becomes one of how much 
overlap can be tolerated before the signal is 
no lcnger readable. I suppose that the ane 
swer has a good deal to do with the decision- 
making process used in the demodulator and 
signal-processing circuits. Common sense 
would seem to lead one to conclude that 50% 
overlap is about as much as a receiving sys- 
tem could put up with. Laport says that the 
signal is mutilated when the prominent de- 
layed wave in the multipath group surpasses 
20%.’ I suspect that a better number is some- 


where between these values. 
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Fig. 1 shows the maximum signaling 
rates in bauds as a function of path distance 
and operating frequency with respect to the 
muf. It is derived from Salaman's work. 

The conversion used to change delay in ms to 
bauds is based on a 50% overlap of code ele- 
ments. If you wish to believe the more pes- 
simistic 20%, then you can divide these 
rates by 2.5 


I suggest that we recognize 75, 150 
and 300 baud rates as standard for hf packet 
operations. Also, we should begin experi- 
ments with 600 baud under an STA from the 
FCC in order to determine whether it should 
also become standard under a rules change. 
Initially, hf packet testing should use 75 
baud to iron out the other bugs. Then, 
testing of higher speeds should proceed un- 
der valid test methods capable of sorting 
out multipath from inadequacies of demodula- 
tors, etc. Operationally, it makes sense to 
operate at the highest speed at the time, 
consistent with good copy. Assuming that 
we find the speed will vary under different 
path conditions, we should consider making 
the speed adaptive. By adaptive, I mean 
that signaling speed should be under soft- 
ware control so that the computers at each 
end can decide on which data rate is best 
for the prevailing conditions. 


Multipath distortion is not the only 
problem facing us on hf. Other types of 
fading, other signals, man-made noise and 
natural noise all conspire to prevent us 
from sending perfect packets through the 
ionosphere. Hams will make a substantial 
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contribution to technology if we can make 
this work reliably. Simply sending packets 
over an hf circuit will result in many re- 
tries (when conditions are not perfect). 
Nonetheless, some of that should be done in 
order to get a feel for the problem. How- 
ever, it now looks very likely that we 
should use some type of forward error cor- 
rection (FEC). An FEC system called AMTOR, 
based on CCIR Recommendation 476, is cur- 
rently being tested overseas.® A small num- 
ber of U.S. amateurs were granted an STA to 
experiment with AMTOR in November 1980 by 
the FCC.9 Jerry Dijak, W9JD is currently 
developing an hf FEC system./9711 There re- 
mains much work to do, both theoretically 
and experimentally. There are some inter- 
esting questions. One is, why do we keep 
throwing out packets which have one or 
more errors in them? Is it practical to 
compare two or three pretty good copies of 
a packet in memory and make a perfect one? 


We need some standard operating fre- 
quencies for hf packet communications. At 
this time, I believe that we need two fre- 
quencies per hf band -- one for network 
operations, one for direct use between in- 
dividual stations (for experimentation, 
traffic handling, etc). 


In February, 1981, I mailed an hf 
packet frequency survey request to a number 
of individuals in locations covering North 
America. Unfortunately, the response was 
not what I had hoped. Rut, J wish to thank 
Bill, W4MIB and Pete, NSTP for the consider- 
able number of hours that they monitored 
looking for activity on the RTTY bands. 
Their results, combined with mine, showed a 
fairly consistent bell-shaped curve within 
the RITY segments. This led to the general 
conclusion that there were some good spots 
just inside the low and high ends of each 
RTTY subband. In addition to monitoring 
for on-the-air activity, research was done 
on published or other known usage.!2 Also 
taken into account were: U.S. Fl alloca- 
tions, 3 Canadian Fl allocations, the " on- 
siderate Operator%’ Frequency Guide,"!3 and 
the IARU Region 1 HF Band Plan,}4 


80 Meters: 
3500- 3775 U.S. Fi allocation 
3500- 3725 Canadian Fl allocation 
3610- 3630 Considerate Opr's Freq. Guide 
3580- 3620 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 


3580 W1AW cw bulletins § code practice 
3003 Southwest CW Traffic Net 
3585 Missouri CW Net 
3587.5 Louisiana RITY Net 
3590 Empire Slow Speed Net 
Third Region Net 
Washington Section Net 
Bier be Georgia State Net 
3020 Pine Tree Net 
3598 Southern California Net 
3600 Kentucky CW Traffic Net 
Kentucky Slow CW Traffic Net 
3602 First Region Net 
3605 Buckey Net RTTY 
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3610 BFastern Pennsylvania CW Net 
Kansas CW Section Net 
Pennsylvania Training and Tfc Net 

SOLS Louisiana Amateur Net 

3617.5 Virginia Specialized Comm. Net 

S620 AMSAT = RITY Net 
Georgia Emergency RTTY Net 

3625 WIAW RTTY Bulletins 

3630 Kentucky RITY Net 
Northern California Net 

3633 New Hampshire Net 

3635 Idaho Montana Net 


Tennessee CW Net 
3637.5 RTITY Autostart 


40 Meters: 


TOUVO= ALSO: i. Sy 


Fl allocation 

7000- 7150 Canadian F] allocation 

7090- 7100 Considerate Oprts Freq. Guide 
7035- 7045 IARU Region 1 HF Band Plan Fl 


Published or other known usage: 


7040 Rastern Canada Net 
Hit § Bounce Net 
7045 Ontario Southern Net 
IARU Region 1 HF Band Plan for SSTV 
7090 Forty Meter Interstate RITY Net 
Gater Net 
7095 WI1AW RTTY Bulletins 


20 Meters: 
14000-14200 U S FI allocation 
14000-14100 Canadian Fl allocation 
14080-14100 Considerate Opr's Freq. Guide 
14080-14100 IARU Region 1] HF Band Plan Fl 
Published or other known usage: 
14075 RTTY autostart 
14076.5 Canadian packet beacons 
14080 W1AW bulletins §& code practice 
14082.5 Heath computers, autostart 
14095 W1AW RTTY bulletins 


15 Meters: 
21000-21250 U.S. Fl allocation 
21000-21100 Canadian Fl allocation 
21090-21100 Considerate Opr's Freq. Guide 
21080-21120 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 
21095 W1AW RTTY bulletins 


10 Meters: 
28000-28500 U S Fl allocation 
28000-28100 Canadian Fl allocation 
28090-28100 Considerate Opr's Freq. Guide 
28050-28150 IARU Region 1 HF Band Plan Fl 
Published or other known usage: 
28080 W1AW bulletins 4 code practice 
28095 W1AW RTITY bulletins 


After review of all information avail- 


able, my recommendations for specific hf 
packet frequencies are: 

Band Darect Network 
80 meters $612.5: KHz 3627.5 kHz 
40 meters 7092 ,0 kHz 7098.0 kHz 
40 meters R1* 7036.0 kHz 7044.0 kHz 
20 meters 14076.5 kHz 14098.0 kHz 
15 meters 21092, 0 kHz 21098.0 kHz 
10 meters 28092.0 kHz 28098.0 kHz 


*R] frequencies are for use in ITU Region f 
and for Transatlantic packet communications. 


Over the past few years, there has 
been a virtually complete phase-out of 850- 
Hz shift for hf fsk. The hf fsk standard is 
now 170 Hz. This has been somewhat of a 
mixed blessing. On the positive side, 170- 
Hz shift occupies less bandwidth thus con- 
serving spectrum in that sense. However, 
at 850-Hz shift, there was considerable de- 
correlation of the mark and space frequen- 
cies. In other words, the mark and space 
frequencies were so far apart that they 
tended to fade independently. This opened 
up the possibility of processing these two 
signals as two separate diversity branches. 
Diversity combining could give equivalent 
gains of something on the order of 8 dB or 
so depending on a number of factors. Ina 
way, this was moot because amateur RTTY de- 
modulators did not take advantages of this 
decorrelation when 850-Hz shift was used. 
I bring this up because we have another 
shot at it. Clearly, 170-Hz shift is not 
what we need to run data rates such as 300 
and (possibly) 600 baud. Bob Watson, a de- 
Sign engineer who is working with state-of- 
the-art demodulation techniques, has given 
this problem a great deal of thought. He 
is proposing that we go to 600-Hz shift. 
This does a number of good things. 600 Hz 
is wide enough that mark and space tend to 
be decorrelated most of the time. It per- 
mits keying speeds up to 600 baud. It 
would allow us to use synchronous transmis- 
sion and reception. Frequency diversity and 
synchronous detection can provide consider- 
able gain. 


Local Area Net Standards 


For the most part, LAN standards seem to 
be developing along the lines of 1200 baud, 
Bell 202 modems, 2-meter simplex repeaters, 
using the VADCG terminal node controller 
board for the individual station, etc. Much 
of this has to do with the availability of 
the VADCG TNC boards and quantities of Bell 
202 modems. The 1200-baud data rate is also 
the highest speed presently authorized by 
the FCC for the 144 and 220 MHz bands. 


Things don't necessarily have to stay in 
this same pattern. In fact, there will de- 
velop a number of reasons why we should try 
some different techniques. If speed is a 
problem at 144 and 220 MHz, of course we can 
move to 420 MHz where the FCC permits 19600 
baud. Someone can make a pitch to the FCC 
to change their rules to allow higher data 
rates at 144 MHz and above. In fact, the 
ARRL has already done so under petition 
#3788. The availability of higher-speed 
surplus modems or an easily reproducible 
printed-circuit board designed by amateurs 
could make the higher-speed modem picture 
a bit brighter. A new board to replace the 
VADCG TNC could change things, possibly by 
reducing the cost. In other words, there is 
more than enough room to experiment. 


My basic point is that we need some com- 
monality to help local networks come about 
but need to encourage local experimentation 
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and innovation. 
Conclusion 


I hope that the foregoing information and 
recommendations contribute to the thinking 
processes in the development of amateur 
packet radio networking. Please understand 
that nothing that I have presented is cast in 
concrete. We are all learning. 


The time to design a packet network is 
now. Many of the people who will do the 
work are at this conference. We can muster 
me talent and resources needed to do the 
job. 


I would like to thank the ARRL, National 
Bureau of Standards, AMRAD membership, AMSAT 
membership, the Bureau Radio Amateur Signal 
Society and numerous individuals who have 
made this conference possible. 
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SOFTNET - PACKET RADIO IN SWEDEN 


Jens Zander, SMSHEV 
Department of Electrical Engineering 
Linkoping University 
S-581 83 Linkoping, Sweden 


Abstract 


An experimental packet radio network is under construction 
at the University of Linkoping, Sweden. The network is 
distributed and all nodes are programmable via the network during 
normal operation. This concept gives full flexibility at all 
levels. Experiments at low levels, such as access schemes, as 
well as at high levels, such as routing and flow-control, are 
possible. Finally, the implementation of the network is 
sketched. 


I. Introduction 


In Sweden, just as in the US the personal computer market 
literally exploded in the late 70’s. The market was, and still 
is, dominated by computers of Swedish origin, Luxor ABC80, as 
well as the american brands, PET, Apple and Radio Shack. Atan 
early stage, the computer clubs at the major Universities took a 
leading part in the evolution of personal computers. In 1975, 
the LYSATOR club at the University of Linkoping had already 
designed and was distributing a minicomputer kit using the IMP-16 
chips for personal use. Also, many radio amateurs got involved, 
and their need for computer communication made the Swedish 
Telecommunication Administration finally allow the use of ASCII 
for transmissions in the amateur bands. 


The idea to organize these computer communication attempts 
substantiated as one of us attended a course Computer Networks at 
USC in Los Angeles. Back in Sweden? the first sketches of the 
proposed wide-band packet radio system were quickly adopted by 
radio amateurs, the LYSATOR club and other persons at the 
University of Linkoping. Soon a close cooperation with a 
research project dealing with digital mobile radio communication 
was. established. This project was among other related issues 


concerned with mobile packet communication, primarily access 
schemes. 


Since then, half a year has passed. Students, both graduate 
and under-graduate, have become involved in the Softnet project. 
The aim of this project is to construct a distributed packet 
radio network, operated ty radio- and computer-hobbyists, for 


experiments with routing, flow control, DDP and many other 
things. The swedish Telecommunication Administration has shown 
interest in the project, and indicated that they will grant 


permission to operate such a network. The frequency band used 
will be 432 MHz, 


II. Softnet concepts 


During the last years several amateur packet radio networks 
have evolved, mainly in Canada and the US. These networks 
consist of a number of users nodes and a_ repeater. All users 
communicate via the repeater and are not allowed to communicate 
directly with each other. This is an example of a centralized 
network (Figure la). The commercial telephone networks are other 
examples of centralized networks. The advantage of this kind of 
network is its simplicity of operation. Routing is trivial, no 
one has to know exactly where the receiver is located. Packets 
are just forwarded to the repeater. There are, however, several 
disadvantages with a system like this for amateur experiments. A 
network of this kind is almost condemned to be a local one, 
unless provision for inter-repeater communication is made. When 
the repeater fails, no traffic exchange is possible. This places 
a heavy burden on the person responsible for repeater operation. 


(a) (b) 


Fig. 1 Network structures 


An alternate, more flexible, solution is to use a 
distributed network ( Figure Ib ). Here every node is able to 
communicate with all other nodes within range. Also, every node 
acts as a repeater for packets, forwarding them in the ‘right’ 
direction towards its final destination. Examples of networks of 
this kind are the PR-net and the ARPA net. Such a network 
eliminates the responsibility problem and makes the system more 
robust. If any node fails, there may be another path for packets 
to take. It is in the owners own interest to keep his node 
running. A node can be installed almost everywhere. The only 
requirement is that another network node is within radio range. 
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When constructing an experimental network without really 
knowing what future demands are going to be, it is essential that 
the network is ‘soft’ at all levels. This is achieved by making 
the nodes programmable. Full flexibility is achieved by allowing 
nodes to be programmed via the network during normal operation. 
This is the Softnet concept. Thanks to this flexibility one part 
of the network can be, for instance, operated as a centralized 
network one day, and as a distributed network another day. Node 
programs are forwarded in packets, just as ordinary data.As_ will 
be seen, this makes it natural not to distinguish between 
programs and data, a feature which is common in many modern 
programming languages. 


III. Problem identification 


There are several problem38 that arise in a distributed 
network. Consider the network in Figure 2. The lines between 
nodes represent possible two-way radio paths. A trivial task for 
a network is to forward a packet from, say node A to node F. We 
can immediately see that there is no direct two-way path between 
those nodes. This means that the packet has to reach its 
destination in a multi-hop fashion. The question then arises, 
which of the nodes to use as intermediate repeaters. We havea 
routing problem. This is a very interesting problem in radio 
networks since we can change the topology of the network by 
simply increasing or decreasing the transmitter power. 
Furthermore, node B may be heavily loaded by other traffic which 
makes node D more suited as the first repeating node. Let us for 
a moment assume that node B is chosen by node A to be the first 
repeating node. We are using a single, wideband, radio channel 
which is shared by all nodes within range. The nodes have to 
agree upon some scheme or algorithm by which this sharing is made 
possible. We have here a_ local communication problem or a 
channel access problem. Finally when a new node, G, is installed 
it should quickly become a full member of the network. This is a 
problem of network control. 


Fig.2 Network example 


We have by this little example identified three major 
problem areas, Routing, Access, and Network control. Being 
strict, to achieve optimum performance these cannot completely be 
held apart [3]. It is, however, reasonable to believe that, if 


these problems are treated separately, near optimum results will 
still be achieved. 


IV. Network programming 


Traditionally, computer networks utilize layered structures 
of protocol3 , i.e. procedures by which messages are handled at 
different leveis. Typically, a protocol uses a number of 
parameter3 which can be set to make the involved stations react 
in a specific way. This method is well suited for fixed networks 
and will easily handle all the situations for which it is 
designed. In an experimental network, surely a __ lot of 


unpredictable situations will arise and this demands another kind 
of solution. 


An obvious remedy is simply not to specify any specific 
procedures or protocol3 at all. Instead, we define a language in 


which possible solutions can be expressed, This language will 
define a _ logical ( mnode- ) machine that can be instructed to 
perform function3 defined by the ( remote ) user. In Softnet, 


FORTH was chosen as the control language. This language has 
several properties that makes it highly suitable as_ network 
language in an experimental environment. FORTH is interpreted 
and its source code is extremely compact . The greatest 
advantage is, however, that FORTH is incremental in that new 
language constructs can be defined by the users. These new 
constructs are used in as general a way as the basic primitives. 


In Softnet each node acts as an interpreter of packets 
containing FORTH statements which are immediately executed. The 
statements are typically ‘treat the rest of the packet as data 
and forward it to node B’, but they can also define new function3 
as ‘forward all my packet3 to node C*. A gmall example may 
clarify the general idea. If we ret-urn to the network in figure 
2, we are now going to let the network perform a_ little more 
difficult task. Suppose we want to implement a 
point-to-multipoint connection, say between node A and both nodes 
C and D, using B as an intermediate repeater. A possible 
solution is to transmit the packet3 shown in figure 3 to node B. 
In the first packet we define a command { FORTH word ) called 
SPLIT. SPLIT is defined to duplicate a packet ( DUP ) and 
forward one copy to C(C SEND) and one copy to D(D SEND ). 
This definition is stored in B and is now ready to be used. The 
second packet makes use of the SPLIT word. The shaded area here 
represent3 a field treated as data, Finally, we can remove the 
definition to save some of the memory space in node B by 
transmitting the third packet in figure 3. 


weasetp yYOOTg - SpON G “3TY 


LIA 7S 11S 


*eFeU0IS WYY UOJ HAOMYOU BUX ETA SpuoM 
OTSEQ BUY JO SUOTSUSA PaSTAsU ayNngtuystp 03 eTQIssod uaaamoy ‘st 
41 *deujysqo0q epou aTqeus 03 SWOYd UT peuteqUoo. sue Jaqyauduayut 
9uqy pue ( SP4OM HLYOd JO UOoTyoaT{TOO e& ) saaTytwtud ofseq au 
°"( WId ) Sd08juequT [eTTeued e pue ( yass ) dtyo uotyeotunumoos 
SnououyousAS e& PFA Td 9844 0F SedeJuaqUT UaATaODSUeUY OTPRU 
qeyoed syy ‘waqshs utew ayy YqTM peueys uazgnq yeHoed e suTeqUOD 
Tud SUL °( Idd ) e0ejuaqUuT OTpeYy yexoeG ayy UT pequewatduT st 
sso00ud YNIT 844 seeuaym ‘uossa00ud utTeWl ay} UT aptseu sassao0ud 
YASN PUe AGON SUL “*apou BYyy JO WeasetTp YOOTQq eB smMOoUS G osuNnsTy 
“UOOTTTS UT sUuTYyoeW Y4AIOT & ATTENJUTA ST YT esSneosq uescuod sem 
Ndd STUL “Ndd 6089 eTCuoqQOW aya Bu daynduoooustw 
JOSSs00ud-omy e ut 


Ee ut Dott suoTa 


* 


sassao0ud Spon f 2Tg 


ee eS ee ee ae 


*(2] 


BoejuaqUuT uasn 38y4q Saingiqsuce ssadoud ygen suq sReausum ‘*ssado0ud 


SGON 243 Aq YIM QTeap sue TOuyJUOD yUOMYSsU pURe BuTyNoy *sqaxoed 
Sau0jS pue UadATsosueuy Yyayoed ayq STOuqUuOd Al “UOT ZeOTUNUWIOO 
TeooT saTpuey ssaooud yNIT euL *( ssa0o0ud ygsn ) weeuqs 4yndut 


TeuTWwusy 38yqy UO ( Saesseo00ud YNIT pue gqqON ) sqexHoed sqzauduaqut 


qeuy deqyeudusequT yquoy azetdwos e Jo sysisuoo sassado0ud 3Sauq4y 
JO yoegd ‘*( f Sunsty ) sassao00ud quauunouod sauyy se paquawatdut 
sue suotyounyJ epou aul *sutdoyuty Jo AriypEuaatun auy qe 


UOFJZONUYSUOD UapuN aue 4JaUuysJOS UOJ sapou ysuTy ayy ATJUasaug 


uot eyusuaTduyt qeuyscs <A 


‘asn [Teuosued sty 
Ssqueduaqzunodo uMo sty 
*SUaJSUPUY 2TTJ pue st leo 


JOJ W3YY PUus4yXd OF YO SSTYITTOePJ esau. Jo 
@4Yesud =04 SsTqe ‘usAemoy ‘ST usUuMO sul 


TenjutTA fsueusZeqep eue saTqyT[Toey yons JO satTduexy ‘"awyq dn-qooq 
qe Solqt[Toel ofseq yuswatdut 04 SOATJIWTud suteqyuoo ATTewu0U 
A4OMJOU SUL “Sapou YUueYsSTp 9uq UT sSeouRe AuoWDsW eyeaAtud ut 
Aj taeuoduiazy suotyzoung ATOZ e404S OF Woy Butqyqtuusd Aq paptoae 
ST Sdasn usemMzeq UOTIORUS4UT peapuaquTUn *uaqynduco peaaingtuistp 
qUETS e& SB pauspTsuod aq ured yuoM aU euL *syseyZ jo SPUTH TTe 
wuojued 03 pesn Aue[nSeu st Butwweusoud ZOePJ ut Anq ‘pauweuSoud 
eq ueo ATUO You ysuqJos VEU SES UBD 3M aTduexe styuy Ag 


SOTJTTTOeJ HAYOMJou MOU But yeauo syeHoed Jo atdwexg € °3tg 


LIITdS LADYOs 


‘GNaS d GNSS O dnd LIIds 


1.9 


OL'l 


The packet radio transceiver is a mixture of standard ana 
special purpose designed components. Figure 6 shows a block 
diagram of the transceiver. The Receiver section uses a standard 
BC IF strip and detector. The bit rate used in the system is 100 
kbps with clock recovery coding for synchronous transmission. 
The signal strength reading ( S ) is digitized and is available 
to the PRI. The transmitter section consist of a PLL FSK 
modulator at 30 MHz. FSK modulation was chosen for its 


simplicity of design and high interference suppression. The 
conversion to the actual frequency band, 432 MHz, is performed by 
a standard transverter. The transmitter section of the 


transverter is modified to enable digital power control. The 
output of the transmitter is less then 10 W. The T/R switching 
is performed in a strip-line PIN diode switch ( described in QST 
May 1981). Provision is also made for testing a_ carrier 
synchronous DPSK modulation system. 


Data 

Tx C/ PKA, PUN 
Data 430 z 5 
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Fig.6 Packet Radio Transceiver «+ Block diagram 


VI. Conclusions 


The Softnet concept is well suited for amateur radio 
computer networks, It provides the flexibility that a network 
designed for experimental purpose3 should have. The 
programmability gives all users the opportunity to conduct their 
own experiment3 during normal network operation. The network is 
highly robust against failures. New users may easily enter and 
leave the network. Based on these properties, it is our belief 


that the Softnet concept is a viable approach to amateur computer 
communications. 
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AN EXPANDABLE MICROWAVE NETWORK FOR MULTIMODE COMMUNICATIONS 


Dave Ingram, K4TWJ 
Eastwood Village #/20! South 


Rt. Il, Box 499 


Birmingham, Alabama 35210 


The projected network described in this 
paper was originally conceived with the purpose 
of interlinking communities and cities on a broad- 
band basis. Numerous other capabilities, how- 
ever, were soon included to permit almost direct 
compatibility with future communication expan- 
sions. The resultant network is highly flexible: 
it may be instigated between adjoining communities 
and/or cities, with additional networks being im- 
plemented in other areas and interlinked as 
desired. Communication modes which can be 
handled by the network are limited only by users 
desires and their respective modes. A basic 
outline of the microwave network shown in Figure 
|, and an overview of its operations follow. 


Network Philosophy 


The primary purpose of the microwave net- 
work is~ providing emergency communications 
between areas or cities normally separated by a 
distance greater than their normal 2 meter com- 
munications range. Secondary communications 
capabilities should be considered at installation 
time, however, since path losses and overall 
network bandwidth are directly related. The 
number of “dumb” or “passive” microwave 
repeaters will be determined by distance and 
terrain between associated cities, each accepting 
responsibility for their part of the link. Existing 
2 meter repeater groups and councils can respect- 
ively provide finances and frequency/code coordi- 
nations. Two transceivers are shown connected 
to each microwave port: one preset on the 
“primary” frequency and the other scanning an 
approximate | mHz range of the 2 meter band 
(Exception : all secondary transceivers’ realize 
primary-frequency lockout). “Secondary” trans- 
ceivers are under microprocessor control ; permit- 
ting frequency scanning, spread spectrum opera- 


tion, tone control of transceiver functions 
(enable/disable, lockout, connect to mailbox, 
etc.). The network could initially develop be- 


tween any two mutually-agreeable areas (each 
preferably with at least two’ local 2 _ meter 
repeaters, since this would confine costs of 
microwave link additions). Additional areas could 
join the existing network by financing their 
respective part while exhibiting their benefits to 
existing network’ users. Assuming a similar 
network is also instigated in other and more 
systems may “grow” until an overall network 
merge is warranted and instigated. Additional 
networks may, likewise, grow and merge with the 
existing system as desired. Further expansions 
may include "spurs" and  subnetworks as 
desired. 


Satellite Interlinking 


Continuing the network a step further, 
interlinking with the OSCAR Phase IV geosta- 
tionary satellites could provide full hemisphere to 
complete world coverage for compatible mode users 
(projected date: 1986). The outline for this 
concept is shown in Figure 2. OSCAR Phase IV is 
slated to include several concepts applicable for 
data communications. Some of these features are 
dedicated channels , tone controlling and mailbox- 
ing. In some instances, a microwave network 
port may interface with an OSCAR earthbased 


transponder. Other times, a separate network- 
to-satellite earth based station will be required. 
The criteria will, naturally, be determined by 
geographic locations of microwave links. 

OSCAR satellites necessarily utilize nar- 
rowband modes such as SSB or CW, however a 
microwave network should’ utilize a constant 
carrier mode such as FM. The key to compati- 
bility between these modes is Constant Amplitude 
Single Sideband, or merely PLL-SSB. This 
concept, which was developed in Europe 4 or 5 
years ago, employs a variable amplitude in the 
normally suppressed carrier. Carrier amplitude is 
miniscule during modulation, but increases to full 
power during breaks of speech (after passing 
through the microwave network, the carrier may 
be fully removed - 
resulting in conventional SSB). Finally, total 
microprocessor control is employed for the link; 
its preprogrammed functions being available for 
call-up by coded tones. 


Technical Aspects 


The concepts associated with microwave links 
are, in several respects, unlike those employed in 
conventional VHF repeater links. Bandwidths of 
microwave systems, for example, are typically .5 
to 4 mHz. Output power levels are noticeably 
lower, with large parabolic dishes providing 
signal gain capabilities. Conventional superhetro- 
dyne techniques are also altered: each microwave 
transmitter runs continuously,, with a_ small 
portion of its output power being directed to its 
receiver's “front end” to provide a local oscillator 
signal. Transmit frequencies of communicating 
units are then offset by a difference equal to the 
desired | F (center frequency). This arrangement 
may be visualized with the aid of Figure 3. _ All 
microwave units are originally transmitting on 
their hypothetical resting frequency. An incom- 
ing signal on 146.00 mHz shifts the transmitting 
unit 146 mHz (a second signal on 146.50 and a 
third signal on 146.80 would appear as subcarriers 
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of the original signal, untilthe 146.00 dis- 
appeared. The 146.80 signal would then be a 
subcarrier of the 146.50 signal would then be a 
subcarrier of the 146.50 signal). Assuming a 
"dumb" relay is required between ports, it would 
receive the 2.146 gHz signal, hetrodyne to 
.146 gHz, IF amplify the signal(s) and apply it to 
the associated transmitter. The 2.146 gHz signal 
would then be received at the subsequent micro- 
wave port, converted to 146 mHz and applied to a 
(broadband) amplifier. That (I. F. ) amplifier’s 
output would feed the "next" 2. | gHz transmitter 
and the 146 mHz transceiver (while also accepting 
146-band input signals from the 146 mHz trans- 
ceiver). The microwave% overall bandwidth could 
easily expand to | mHz, as necessary, with all 
data/tones being moved in a conventional manner. 
All operations and frequency determinations of 
network - located 2 meter transceivers are under 
microprocessor control. This means that port- 
available signals may be selected or rejected by 
tone control, as desired. Preprogramming of the 
microprocessor establishes basic network 
standards. 
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Two microwave! bands are prime candidates 
for network links: 2.1 gHz and 1O gHz. Gunn- 
plexers are readily available for 10 gHZ systems, 
however their individual-link range is limited. 
Similar units for operation on 2.1 gHz will soon be 
available from Universal Communications, P. 0. 
Box 339, Arlington, Texas 76010. The 2.1 gHz 
units are 100 mw or | watt., as required. cost of 
10 gHz Gunnplexers are approximately ||5 dollars 
each. Cost of 2.1 gHz2 units are approximately {70 
dollars each. 

Returning to Figure | and applying prev- 
lously acquired knowledge, a_ brief technical 
discussion will now be presented. 

Assume an amateur operating on 146.76 
desires to contact a_ distant repeater on 
146.76 mHz. A .76 signal with PL tone is used 
for connecting the scanning transceiver into the 
network. Notice the distant ‘94 transce:ver 
employs “lockout”, preventing accidental access. 
Another 3 digit code “brings up” the desired 
distant ‘76 scanning transceiver , with subsequent 
microprocessor control establishing operating 
parameters for accessing that area’s ‘76 repeater. 
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Assuming the distant amateurs desire disconnec- 
tion from the link (or the calling station desires 
distant disconnection) another 3 digit code will 
“bring down" that transceiver (example: 128). 
Data packets may be moved either to the distant 
repeater, or left in the electronic mailbox as 
required. Continuing overall system capabilities 
one step further, we can use tone control and 
port-located microprocessors for handling fre- 
quency offsets and Spread Spectrum hopping 
sequences. This capability would permit an 
individual amateur operating on 146.52 mHz to 
"catch" the network’s’ scanning _ transceiver, 
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establish different network - relayed frequencies, 
ard proceed in the previously described manner 
(Example: 146.52/.52 into network, 146.16 out of 
network. One or two fully microprocessor- 
controlled transceivers required for this option). 


A full description of the network would, 
obviously, encompass numerous pages of dis- 
cussion. We thus leave those operations open for 


your investigation and expansion. The network 
outlined is a coarse system for future communica- 
tions techniques. We hope this "first basic step" 
will inspire unlimited expansions. 
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DEAF TELECOMMUNICATIONS NETWORKING 


Barry Strassler 
Executive Director 
Telecommunications for the Deaf, Inc. 
814 Thayer Avenue 
Silver Spring, Maryland 20910 


Thank you every one of you for giving me 
the opportunity to give you a glimpse into 
the world of deaf telecommunications. It 
should be of interest to you because our 
technology interrelates with yours in many 
ways, and perhaps might even spur you on to 
better developments. 


Life is full. of historical accidents 
that shape the course of history. The par- 
ticular historical accident that I wish to 
bring up refers to one of your people, a 
deaf one at that. In 1964, Robert Weit- 
brecht, of California who is one of the 
world’s few deaf licensed radio hams, was 
hiking in the mountains with a group of 
friends. Another group of hikers converged 
onto Weitbrecht 's group. In that second 
group was a couple whose son is deaf. That 
couple overheard a very distinct speech and 
knew that it was from a_deaf man. This 
couple walked over to Weitbrecht and intro- 
duced themselves to him. In the course of 
conversation, this couple learned of Weit- 
brecht's diverse interests, one of which 
was radio-TTY. Coming home, this couple 
related this encounter to their deaf ac- 
quaintance. This acquaintance knew of a 
deaf dentist who had wished for some sort 
of telephone communications tool to be able 
to reach his clients. One thing led to 
another, and introduct inns were made all 
around. This deaf dentist inspired this 
deaf radio ham/hiker to come up with such 
a TTY device for the deaf. This is how his- 
tory was made. 


Our present TTY or better known as TDD 
(Telecommunications Device for the Deaf) 
network consists of 75,000 installations 
aJl over this country. This phenomenon, 
starting slowly in 1968 and growing by leaps 
and bounds each year, is not without its 
curses as well as its blessings. The bless- 
ings we all know about. But the curse is 
the ASCII/Baudot controversy. In 1964 when 
Weitbrecht came up with his prototype TTY 
modem, it was designed to work with then- 
current teletypewriters using the Baudot 
code. He chose this code for convenient 
reasons which were valid at that time -- 
availability of surplus Teletype Corporation 
machines by communications carriers, ASCII 
technology being so new and not fully under- 
stood, ASCII parts and equipment being so 
costly and way above the means of the aver- 
age deaf households. At any rate, we are 
witnessing a spectacle -- the 75,000 TDD 
units, all of them predicated on the Baudot 
code, being considered very useful but very 
obsolete when we look at the ASCII tide 
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engulfing us today. We should switch to tht 
ASCII code, but it just: cannot take place 
over night. This would suddenly disenfran- 
chise those deaf TDD users, many of them 
from low-income households. 


A way to bridge this ASCII/Baudot gap is 
a dual modem capacity. The average TDD has 
a life expectancy of some five years. So it 
is in the replacement dual-modem TDDs that 
we hope will slowly swing the pendulum to- 
wards the ASCII camp. Protocols are another 
matter. If I had made this speech a year 
ago, I would not be so sure o:f protocols. 
You see, when a flashing light indicates a 
telephone ring in the hcume of the deaf, we 
would have to determine whether it is a 
voice, Baudot or ASCII call. It would be 
cumbersome to fiddle around with full 
duplex/half duplex and with originate/answer 
switches. But today, technology has come up 
with an automatic ASCII/Baudot detector, so 
this set of protocols is taken care of. 


Now we are into electronic mail systems. 
There are several such systems which have 
served the deaf. One of them is DEAFNET 
which serves the Washington, DC and the San 
Francisco Bay deaf communities. It has 
ASCII/Baudot capabilities. Another one was 
the Hermes System which served the Boston 
area before funding ran out. But replacing 
the hermes is the GTE Telemail System. The 
Hermes was self-containing in that it was 
restricted for the use of the deaf only, 
and ASCII terminals had to be used. Now 
they have the GTE Telemail, which is a 
piggy-back system. Here, in. addition to 
DEAFNET, we have the Virginia TTY message 
system which is totally Baudot. All this 
is very promising for us in the years to 
come. 


We have been asked by many radio hams 
about the possibility of the deaf getting 
involved with radio-TTY, This is another 
possibility, but not_ without *problems that 
must be overcome. One is attitude -- the 
deaf like to ragchew with another deaf ac- 
quaintance; because there are so few li- 
censed deaf hams around, this is a factor. 
Second is the matter of taking Morse code 
exams. There is always that hearing im- 
pairment will thwart the mastering of the 
Morse code. Perhaps this is psychological, 
but it still must be overcome, Third is 
the lack of familiarity with the various 
kinds of radio equipment, such as short 
wave, Citizens Band, pagers and the like. 
We, the deaf, look on all of these as one 
thing, and it seems very perplexing. 


I personally feel that if my organization 
and your organizations work together on 
some kind of educational campaign to in- 
terest deaf technological enthusiasts in 
the ham radio field, then progress can be 
made. JI travel a lot and am forever be- 
sieged by frustrated deaf radio-hams-to- 
be. So the interest is there even on a 
small scale. 


There is much more to the future of 
communications for the deaf aside from the 
telephone, the computer and the radio, Your 
world is laden with advanced communications 
devices. With ingenuity being present, it 
would be remarkable that every kind of de- 
vice that you use for communications pur- 
poses will have its for-deaf modifications. 
This is our dream now a.nd in the years to 
come. 
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FROM RTTY TO PACKETS 


Joe Kasser, G3ZCZ 


Introduction 


Putting a microprocessor into an RTTY station 
can improve the usefulness of the station by orders 
magnitude. RTTY comes in various aspects: there 
is the old fashioned Baudot network chugging along 
at 45.5 bauds; the new ASCII links are running at 
300 bauds and exchanging computer data; and, up and 
coming are the packet radio networks. This article 
discusses the whole arena of digital communications 
and shows how each is a step in the whole picture; 
and how as computers are added,, a digital network 
canbe developed that can accommodate users with 
almost any equipment so that radio amateurs having 
incompatible equipment (e.g., a Model 15 Baudot 
machine and an ASCII terminal) can communicate via 
microprocessor based repeaters, 


Digital Communications 


Digital communications at this time refer to 
Morse code or RTITY communications. Morse code is 
a digital communications medium in which the pre- 
sence or absence of a signal and the spacing of the 
signals define the content of the data. RITY com- 
munications use either Baudot or ASCII codes to re- 
lay written information which is displayed by a 
radio teletypewriter or, as is becoming more evident, 
a cathode ray tube terminal. 'This section deals with 
RTTY communications at vhf/uhf. 


Vhf/uhf RTTY is usually transmitted using audio 
frequency shift keying (afsk) on fm equipment. 


Transmissions can be asynchronous random length 
using ASCII or Baudot codes, or fixed--format packets 
of data using ASCII or some other 8-bit word code, 
Putting microcomputers into the communications link 
can allow anybody equipped with digital communica- 
tions hardware to communicate with anybody else also 
equipped with digital communications hardware, even 
if their equipment cannot communicate directly. 

Thus, G3ZCZ/W3 who has ASCII NO-baud equipment could 
communicate with WA3LOS who is equipped with a Baudot 


Model 15 teletypewriter. This is an ideal way to 
provide for low-cost, low-speed communications at ad- 


vanced levels. This paper examines various aspects 
of digital communications. 


RTTY Repeaters 


The usual RTTY repeater usuallyprovides cov- 
erage of a large metropolitan area. The frequencies 
of 146.10 MHz (input) = 146.70 MHz (output) have 
been assigned to such repeaters in the USA, although 


This is apreprint of material submitted to a publisher. 


1.17 


often other frequencies are used. Simple repeaters 
receive the afsk tones and reradiate them directly 
just as if they were audio signals in a conventional 
repeater, More advanced repeaters demodulate and 
then regenerate the signals. 


RTTY repeaters first came into operation for the 
same reasons that audio repeaters were utilized, They 
can provide an extended coverage area as shown in 
Fig 1. Thus in the coverage area, anyone having 
suitable equipment can copy signals on the frequency. 


RTTY, however, is a slow mode of communicating. 
Most people cannot even type at 45.5 bauds, and even 
when sending pre-stored messages at fuli machine 
speed, messages still take a long time to send. A 
two-way RTITY contact can take an hour or so to pass 
information that can be passed in minutes by voice. 
RITY does have one major advantage over voice commu- 
nications, however, and that is unattended operation 
or autostart capability. 


RITY Network 


The RTTY network works as follows. All stations 
monitor the same frequency, either at hf or vhf., Mes- 
sages are sent blind: that is, when a message is ori- 
ginated into the network, the sender does not know for 
certain if the destination station is monitoring the 
frequency, unless contact is first established. In 
the evening, or at weekends, this may not pose much 
of a problem because the probability of someone being 
at home is great. However, by day, that probability 
decreases, Thus, if contact cannot be established 
directly, the message can still be sent, but there 
is the probability that the destination will not be 
on line, and it will be lost, 


If the message can be stored in a central com- 
puter by the sender, and then retrieved later by the 
receiver, the probability of successful transmission 
of the message from sender to receiver becomes a 
certainty. The addition of a computer thus becomes 
an asset to the network, 


If several stations in the network have compu- 
ters capable of answer back, the utilization of the 
computer may be reduced, Asender can put out a 
direct call, If an answer is not received (indica- 
ting that the destination is not on line or monitor- 
ing at the time), the message can either be trans- 
mitted to the computer for storage or held and trans- 
mission retried at a later time, It is also possible 
for the network computer performing the store-and- 
forward operation to rotate among the various member 
station computers on an as available basis as 
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long as the network computer has a distinctive ident- 
ification. 


Some repeaters allow ASCII signals at data rates 
of 300-1200 bauds to be carried. Stations with Bau- 
dot equipment cannot directly communicate with sta- 
tions having ASCII equipment. The network computer 
can contain a converSion capability wherein messages 
received on one mode would be converted to and re- 
transmitted using the other mode. 


In use, ASCII messages would be relayed directly. 
The high-speed ASCII message being input would be 
stored in a memory buffer and an output program would 
transmit the contents of the buffer at 45.5 bauds 
even while the buffer is filling up at the ASCII data 
rate. Incoming Baudot messages can either be trans- 
mitted directly in ASCII at the higher baud rate (but 
still at a real character spacing of 45.5 bauds) or 
can be stored and then transmitted later as a single 
message at full speed. In the latter Case, some sort 
of tone or signal would have to be placed on the out- 
put frequency to notify all users that an incoming 
Signal is present and is being stored but not trans- 
mitted. It would probably be better in this case to 
retransmit the Baudot message as it is received and 
then follow it with the ASCII message upon completion 
of the reception. 


In use, the operator at his station types up and 
transmits a message. The message is transmitted 
directly to the target station or is stored in the 
computer. Some time later, the operator will check 
to see if a reply has been received. Depending on 
the degree of sophistication of the network, he may 
even be able to interrogate the network computer to 
see if the message has been forwarded. ‘Thus, the 
concept of store and forward in the network computer 
is really a logical extension of autostart techniques, 


These techniques for Baudot/ASCII conversions 
allow amateurs equipped for different modes of oper- 
ation to communicate. The scheme presented above 
does suffer from the limitation that only one mes- 
sage can be transmitted at any one time, 


The Baudot network can be classified in the 
dumb range, The users of this network are usually 
operating in the manual mode, possibly using paper 
or audio tape to facilitate operations, Incoming 
messages are printed out and possibly punched on 
tape, Very little selectivity exists to separate 
messages addressed to a station from others on the 
frequency, (A few hard-wired selective calling units 
do exist.) Error detection and correction techniques 
are minimal, 


The ASCII network can be classified as a semi- 
Smart network. Most users have some kind of micro- 
computer-based system. Communications are at 300- 


9600 bauds, but again have a minimal amount of error- 
correction facilities. This network can be used to 


transfer files between computers and in fact is being 
used as such. 


The packet network can be classified as a smart 
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network since error detecting and correcting tech- 
niques can be used. Thus, if the receiving station 
detects an error in the message, it can automatically 
request a retransmission of the bad message to en- 
sure that the traffic is correct. 


Burst Mode Communications 


Consider a digital repeater operating at 1200- 
9600 baud ASCII. Each user has a small microprocessor= 
based terminal that contains a minimal amount of hard- 
ware and software to perform the following operations: 


1) store a few lines of text; 

2) remember who the message is going to; 
3) remember the call sign o:f the station; and, 
4) 


display incoming and outgoing message. 


These capabilities are not too advanced on cur- 
rent smart dedicated microprocessor-based RTTY ter- 
minals. 


In use, any amateur would start typing a message 
at the terminal, When a line of text has been input, 
the microcomputer would check the frequency to see 
that it was clear and then transmit that line of text 
at the high-speed rate (verifying it on the repeater 
output frequency to ensure that it was reradiated 
properly), The amateur typing away at the terminal 
need not even know when the transmission burst is 
sent. Since most people type slowly compared to 
1200-9600 bauds, the terminal will spend most of its 
time in the non-transmitting state, Thus, a number 
of amateurs could be using it at the same time, Any- 
one monitoring the channel would pick up all the sig- 
nals, Each line of text could belong to differing 
messages and thus would appear to be garbled, If, 
however, each line of text was prefixed by the call 
sign of the target station (and suffixed by the call 
Sign of the sending station) and the microprocessor 
in each terminal was programmed to respond to and 
display messages only addressed to its call sign, 
the traffic on frequency would become invisible and 
this time sharing of the repeater would be unnoticed 
by the users, in that incoming messages would be 
displayed a line at a time instead of a character 
at a time as in the conventional network. These lines 
of text that are transmitted in a. burst mode can be 
called packets of data. 


Once a microprocessor is put into use jn storing 
the input characters and then bursting them out as a 
packet, it can also be used to provide some error- 
detection capabilities. 


Packets 


A packet of data can be considered as a high- 
speed burst of information. The typical RITY fre- 
quency can be oeecupied only by one QSO at a time, 
and data is sent at the rate that it is typed. Thus, 
although a Baudot network can pass data at 60 words 
per minute (wpm) using conventional mechanical tele- 
typewriters, a real data throughput of 60 wpm is 


only achieved when running at machine speed. Since 
the actual typing speed in a contact varies as a 
function of the digital dexterity of the operator, 
the data throughput is slow. Computers can be used 
to speed up the flow of information and improve the 
channel occupancy. 


Suppose the data being typed is buffered by the 
computer. The contents of the buffer can then be 
output at high speed (say 1200-9600 bauds) as a 
burst. If the computer checks that the channel is 
unoccupied before transmitting,, there will be a min- 
imal amount of loss of data due to interference (two 
stations transmitting simultaneous bursts are the 
only practical cause of such interference). If each 
packet or burst was prefixed by the call sign of the 
destination station, it would be uniquely identified, 
The computer at the receiving station would ignore 
all bursts addressed to other stations. Thus, many 
QSOs could take place timesharing the channel, An 
example of such a scheme is shown in Fig. 2, Any 
station could display all information relayed or 
just the messages addressed to itself. Thus, the 
addition of a minimal amount of software would im- 
prove the use of the basic RITY repeater network, 


Once computers are used for high-speed data 
burst communication links, advantage may be taken 
of the capabilities of the computer to provide error 
checking and correction capacity, Thus, protocols 
can be defined and adopted with those ends in mind, 


The main problem here is that new stations 
joining the network can bomb it if their equipment 
(hardware or software) is not working correctly, 

If an average of one new station per week joins the 
network and bombs it for two evenings each time, the 
network will suffer a lot of down time. 


Several techniques can be used to minimize this 
problem. The station software can be tested out on 
a simplex or different channel, or a cheap special- 
purpose microprocessor-based circuit card could be 
developed that would act as a front-end processor 
fitting between the computer and terminal unit. It 
would contain the buffers and network communication 
algorithm. Anyone wishing to access the network 
would be required to obtain the unit in a similar 
manner to the way that a tone burst or sub-audible 
tone is required for access to a large number of 
two meter (audio) fm repeaters. The front-end pro- 
cessor card could be mass produced at low cost once 
protocols are established. If designed properly, 
the protocols could be PROM-based and the same unit 
could be used for a number of different protocols by 
plugging in a different PROM for each protocol in 
the likely event that different protocols be estab- 
lished in different networks. 


The actual protocol provides a means for ensur- 
ing error free transmission of a message and is 
transparent as far as the message itself is concerned. 


The analogy in conventional amateur radio is 
that the sounds emerging from a loudspeaker at the 
receiving station are the same as those entering the 
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microphone at the transmitting station, In an inter- 
ference free situation it does not matter to those 
sounds if the modulation technique was am, fm, ssb, 
or dsb. 


The Packet Network 


The packet network is set up for stations who 
can communicate directly using packet techniques. 
The advantages of packet communications are many 
and include the timesharing of the channel, rela- 
tively high speeds and error detection and correc- 
ELON; 


The block diagram of a packet network would be 
identical to an RTTY Baudot orASCII network, but 
packet transmissions offer one big advantage in that 
a packet repeater can operate in the simplex or 
single-frequency mode. In this network, all stations 
monitor the same frequency. All stations can trans- 
mit to and receive from the central store-and-forward 
station (repeater). In use, a station would store 
the message as received. It would then transmit the 
message on the same frequency so that the intended 
recipient would be able to receive it, If the in- 
tended recipient was not able to copy the original 
message, it would be able to detect that it had re- 
ceived the same message twice because the repeater 
would have set a flag byte in the message header 
indicating that the packet was a relayed version. 


The conventional repeater requirement for two 
frequencies (input and output) at one time has now 
been replaced by the requirement for two time frames 

(original (input) and retransmitted (output)) on one 
frequency, 


Network Communications Language 


The Baudot and ASCII RTTY networks require some 
routing signals to ensure that messages are routed 
to their intended destinations. A suitable source 
for these signals is the Q Code commonly used by 
radio amateurs., The use of slightly modified Q Code 
Signals will make the messages easily readable by 
both man and machine, 


For example, a message such as 


WR3ABU :0SP: WA3VXE  :0S0: ALAN 
PLEASE CALL ME ON THE TELEPHONE AFTER NINE 


TONIGHT : QSL: DE G32CZ/W3 


is almost already understandable even without explain- 
ing that 

:QSP: means relay to call sign follow- 
ing 


(please) 


:QSO: the message following 


:QSL: end of message/confirm reception, 


In other words, the store-and-forward computer 
at WR3ABU was asked to forward (QSP) a message to 
WASVXE and confirm its reception by G3ZCZ/W3. Later 
on when WA3VXE signs in to the network, he would 
send 


WR3ABU :QRU: DE WA3VXE 


which means WR3ABU do you have any messages for 
me. 


WR3ABU would reply 
WA3VXE :QRU: G3ZCZ/W3, WB2YUX/3, DE WR3ABU mean- 
ing that there are messages from G3ZCZ/W3 and 
WB2YUX/3. 

WA3VXE would then send either 

WR3ABU :QUA: DE WA3VXE 

or 

WR3ABU :QOBM: G3ZCZ/W3 DE WA3VXE. 

If you know the Q Code, 


means send me all new messages, 
me the message from "=----". 


you will know that QUA 
and QBM means send 


Other examples are: 

WR3ABU :QRT: DE G32CZ/W3 

which signs G3ZCZ/W3 off the network. 

WA3VXE :ORL: DE G3ZCZ/W3 

which asks WA3VXE if he is busy, No response 
within a short period of time means that he is not 
there. If he is, the replay would be 

G3ZCZ/W3 :QRU: DE WA3VXE 

i.e., an automatic answer back. 

Note that WR3ABU would not respond to the QRU 
because its call sign was not recognized, G3ZCZ/W3 
would then send his message as follows: 


IT LOOKS LIKE WR3ABU IS DOWN, 
:Q0SL: DE G3ZCZ/W3. 


WA3VXE :QSO: ALAN, 
50 I TRIED YOU DIRECT 
The response would come in a flash (or at least 
at 60 wpm) 


G3ZCZ/W3 :QSL: DE WA3VXE 


even if WR3ABU was monitoring the transmission 
and recognized its call in the text, since the call 
sign was not immediately followed by the :Q sequence, 
it would forget that it had just recognized its call 
and go back to sleep. 


Hence, 


A message in the form: 


WR3ABU :QOSP: GB3LO :QSP: 


G8BTB :QSO: PAT ARRIVING 


1, 26 


ON THURSDAY 22 JUNE :QSL: DE G32CZ/W3. 


Would instruct WR3ABU that a message is. to be 
sent to GB3LO who will then forward it to G8BTB. 
This extension assumes that GB3LO is the store-and- 
forward computer in a second network in which G8BTB 
is operating. 


The ":" placed before and after the three let- 
ter group of the Q Code makes recognition and de- 
coding easier since all control language statements 
begin with :Q and az is the fifth character in the 
sequence. An example of some of the Q codes suit- 
able for use in the dumb and semi-smart networks 
are shown in Fig. 3. 


Amateurs using Baudot equipment would have to 
type the control language statements in full. Those 
having microcomputers could type ASCII control char- 
acters which would be software converted to the 
equivalent S-letter control group,, 


Network Control Language 


The Network Control Language (NCL) provides the 
computers with information as to what is to be done 
with the data in a message. Numerous languages exist 
to provide computers with instructions, but few exist 
for communications purposes. NCL is written in some 
other language and is not a true language as such, 
but is an implementation of an NCL Program in which 
the man-machine (or machine-machine) dialog is in 
specific format. Most radio amateurs are familiar 
with the Q code. Words such as QRM, QSL or QSO 
are understood by them all. Others, such as QRA 
or QSP, may not be understood unless the radio ama- 
teur is used to traffic handling; but, since they 
already have some knowledge of the Q code and-- 
better still--an idea of the concept behind it, 
the Q code is an ideal language f'or telling the 
computer how to route or process data. 


The NCL based on the Q code can be used at all 
levels of digital networking, starting with a lowly 
Baudot circuit all the way up to a packet network 
carrying video as well as audio packets of data. 

Of course, the packet network with its fixed length 
packets can simplify the actual transfer of data by 
using positions in the packet to convey information, 
Thus, the call sign of the sending or receiving 
station could always be placed in a certain position 
in the packet, rather than--as in the random length 
RTTY message--use the Q code to specify originator 
or destination. 


NCL is used to communicate with the communica- 
tions software in the computer ox in a stand-alone 
packet terminal interface. Apart from the use of 
the ¢ as prefix and suffix for the control word 
(example; sQRM:) the Q code can be used pretty much 
in the conventional meanings. Thus, the Q code 
shown in Fig. 3 can be converted to NCL as shown 
in Fig. 4, The call signs can also be expanded 
upon, drawing upon the usage of wild card charac- 
ters used in several microcomputer operating systems. 


Theme wild card characters are known as general call 
characters and allow the sender to send a message to 
a category of stations. 


The "?" character may be used to match any sin- 
gle character, or number, For example, G3Z?? matches 
any call sign in the G3ZAA-G3ZZZ series. W1??? mat= 
ches any Wl call with a three letter suffix. The "*" 
character matches any section of a call sign (inclu- 
ding a null character) as follows: 


G3* matches anybody with the G3 prefix 

G*¥* matches anybody with the G prefix 

GM3* matches all calls with the GM3 prefix 

*3* matches any call with the three digit in it 
wkk = =2omatches any call in the world 


"The two general call characters can be mixed at 
will, For example, G*3A?? will match any call in the 
United Kingdom in the G3AAA-G3AZZ series, including 
those with the GM, GW, GC, GJ, GU, and GB prefixes. 
Thus, GB3AAA, GM3ART and GW3AAA would be matched. 
Note that G3AA would not match because three ? char- 
acters were used. 


Network Implementation 


RTTY, packets, ASCII, how do they interconnect? 
How does an amateur who only has a Model 15 RTTY 
machine communicate with an amateur who has a packet 
terminal? Should he? In the conventional communica- 
tion modes an amateur who only has a Morse Code (cw) 
station can communicate with another amateur who is 
using voice (ssb), but neither of these can communi- 


cate with someone else using the teletypewriter (RTTY). 


There are many Baudot stations in existence; newer 
amateurs may come on the air with ASCII using micro- 
computers and advanced amateurs can use packet tech- 
niques. In general or random communications, in 
which one amateur calls CQ and wants to see who 
(what?) comes back, all modes usually work other 
stations equipped with the same mode, Thus, Baudot 
RTTY stations have established frequencies within the 
amateur bands where they have the greatest probabil- 
ity of finding others suitably equipped. It is con- 
ceivable that ASCII and packet stations could do the 
same. The big advantage of packets and computers in 
the RTTY area is that delivery of messages can be 
guaranteed, and by using a hierarchy of rf links, 
messages can be relayed between amateurs having dif- 
ferent digital equipment. Thus, a Baudot station 
could send a message to an ASCII station. 


Consider the hierarchy involved: many local 
area nets exist using Baudot equipment. These nets 
may be on vhf or on hf, Each mode has its advantages 
and disadvantages. Fig, 5 shows a potential situa- 
tion for interconnecting such a network with a new 
ASCII network in the same local area. 
implementation, two repeaters are co-sited, One is a 
conventional Baudot RITY repeater, the second an ASCII 
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In its simplest 


repeater, In the normal mode the two are separate; 
ASCII stations talk to ASCII stations at 300 bauds 
or even at 1200 bauds and Baudot stations talk to 
Baudot stations at 45.5 bauds, 


However, by using a translator, Baudot stations 
can communicate with ASCII stations, since the 
translator will perform the code/speed conversions 
from one to the other, The translator can in a sense 
be thought of as a third repeater, 


Each network can operate independently, When 
somebody on one network wishes to send a message to 
someone on the other, he can use the network control 
language based on the Q code to instruct the trans- 
lator accordingly. The translator should thus be 
able to store the message for later forwarding in 
case the other network is carrying traffic at the 
time that the message is originated, The transla- 
tor will transmit the message later when the other 
network is free, or can hold it until the intended 
recipient signs in (on either network) and requests 
his message, 


The translator can be used to perform the 
store-and-forward function for both networks at 
the same time, Once computers are put into the 
network, they can perform as many or as few tasks 
as their owners desire, The different functions 
can be split up between computers, gall the com- 
puters in the network can have the capability to 
perform all the tasks, thus providing a high degree 
of redundancy and reliability in operation, 


Network Hierarchies 


The lowest level is the 45.,5-baud Baudot net- 
work, Baudot machines are usually available for 
less than $50 at local hamfests. They can be Large 
and noisy, but they work and can easily be inter- 
faced to a computer. They can thus be used in basic 
or conventional RTTY stations and then when a compu- 
ter is incorporated 1n the station, can be used as a 
hard-copy printout device or even as a system console. 
Since thousands are already in use, they should not 
be obsoleted just because newer and better things 
such as 1200-baud ASCII are now available. Their 
limitations will soon become apparent to the user; 
who will then upgrade to the newer and better de- 
vices, passing the Baudot equipment to someone else, 
allowing them to join in the fun. Thus, Baudot 
operators will still be able to enjoy simplex con- 
tacts at hf and uhf, 


The next level is the ASCII user, Here the 
baud rates can go as high as 9600 baud and yet re- 
main within a 3 kHz audio bandwidth. Common tone 
pairs used by amateurs in the USA are Bell 103 
tones for 300/110 baud contacts and Bell 202 tones 
for 1200 bauds. It is thus possible to build a 
digital repeater that can monitor the incoming 
Signal and perform conversion to a different code/ 
tone pair for retransmission on the output. An 
example of such a device is shown in Fig 6. The 
incoming signals are demodulated and converted to 


serial data by the different receive terminal units. 
These are fed to a microprocessor module via serial 
ports. The microprocessor is operating as a dedica- 
ted controller in this environment. Under normal 
conditions, the microprocessor retransmits the sig- 
nals in the same format as they were received. Thus, 
if 45.5-baud Baudot signals were received, that is 
what would be transmitted. If, however, the message 
is prefixed by a control code, the microprocessor 
would cause the signals to be transmitted using a 
different modulation technique. The microprocessor 
would also perform speed conversions as well as time 
conversions and provide first-in, first-out (FIFO) 
buffer an the event that the retransmitted signals 
were at a slower baud rate than the input signals. 
With this kind of arrangement, amateurs with 1200- 
baud ASCII terminals will be able to communicate 
with other amateurs having Model 15s or similar 
Baudot equipment. The limitations of 45.5 bauds, as 
compared to the high speeds, will soon cause a de- 
crease in the number of stations using Baudot and a 
corresponding increase in the number of ASCII oper- 
ators. This approach, however, does allow the new- 
comer to join in with a minimal investment, encour- 
ages upgrading of equipment (by example), and does 
not penalize those with older equipment. 


The basic data link allows errors to creep into 
the message. Errors are caused by noise or inter- 
ference entering the communications path. In most 
of today’s amateur digital communications the occur- 
rence of errors are not too serious and can easily 
be detected by visually scanning or reading the re- 
ceived text, When computers are doing the communi- 
cations, they also have to have a means to detect 
that errors have occurred in the transmission of the 
message. 


Linking of Networks 


The discussion so far has limited itself to 
Single area networks serving a common set of users. 
The requirement to interlink networks exists. Being 
radio amateurs, the interlinking technology will of 
course be by radio. An example of interlinked area 
networks is shown in Fig 7. In the figure, each 
network has at least two links to the outside world. 
The link may be through the central store-and-forward 
computer or it may be through one of the users. For 
example, if it is used to link two networks, the link 
may be either via the central computer or via the 
user, but if vhf/uhf is used, the link would probably 
be via a user who is located between the two networks 
and is able to access both directly (possibly only 
with the assistance of high power and directional 
antenna). 


The communications on the interlinks use the 
packet mode. This is because the links will probab- 
ly have lower signal-to-noise ratios than the vhf/uhf 
local network paths and the probability of interfer- 
ences is greater. 


Conventional vhf links also suffer from a rout= 
ing problem. How does a message get from network G 
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(in Fig. 7) to network A? 


Does the originator specify the routing, the 
final network store-and-forward call or nothing at 
all? Which algorithm is to be used = fixed path «= 
random, etc? Professional networks have spent thou- 
sands of dollars on this problem. Radio amateurs 
also cannot guarantee that all the links will be 
operational with a reliability of 0.999. What hap- 
pens when a network node goes down for a while = 
are messages going to get backed up, are they going 
to get lost? 


Hf propogation also suffers from its own char- 
acteristics, The ionosphere that reflects back 
the hf radio signals is a dynamic medium. Its 
properties change from minute to minute, are dif- 
ferent during the day and the night and are affected 
by solar activity which may enhance or detract from 
the reflecting properties of the inonosphere at any 
particular frequency. Thus, the situation shown in 
Fig. 8 is typical of the conditions under which 
radio amateurs operate. Stations A and B are in 
direct contact with each other. Station C can also 
hear A but cannot hear B. If station B is trans- 
mitting, Station A will be silent. When Station A 
is silent, Station C may try to send a packet to 
Station A and interfere with the packet that Sta- 
tion B is sending. Station D, who cannot hear any 
of them at this time, may transmit to someone else 
and as conditions change will interfere with A, B, 
or C. This situation is not impossible, it is just 
difficult to design around. 


Several techniques have been developed to min- 
imize the QRM situation, Each station in the net- 
work can transmit at random. If a collision be- 
tween two packets occurs, i.e., one interferes 
with the other, the receiving station will not be 
able to send an acknowledgement to the sending 
stations so the sending station will try again 
later. If each station waits a different random 
amount of time before transmitting its packet, 
there is a good probability that the second time 
that a packet is transmitted it will get through. 


Another alternative is to give each station 
a fixed time slot for transmission. Thus, Station 
A would always transmit during the first second of 
any minute, Station B during the second, and so on, 
If the stations are referenced to WWV or any other 
standard frequency and time transmission, a mini- 
mal amount of interference will occur, but the 
throughput will go down since a station may have 
no packets to send but that time slot will still 
be reserved for it. 


Adding the interference problem to the rout- 
ing problems, hf networks are in themselves a prob- 


lem. 


One solution could be to use a random trans- 
mission sequence based on the probability of a 
successful contact, This means that messages are 
only originated if there is a good probability 
that there will be propagation to the destination 


or target station at that time of day. 


Given that a system in which everybody cannot 
hear everybody else, in which propagation is uncer- 
tain is a difficult system to operate, it follows that 
the converse is true = i.e., a system in which every- 
body can hear everybody else, in which propagation is 
100% predictable is ideal. This situation occurs if 
a communications satellite can be utilized as the re- 
laying medium. 


Fig. 9a shows the same four stations now using a 
communications satellite to relay messages, They can 
all hear each other, and since the orbit of the sat- 
ellite is known, they can compute the time when prop- 
agation will be possible between any of them. If the 
AMSAT Phase III or Phase IV satellites are used, each 
covering large areas of the world, a global network 
takes on the shape of a local network as sketched in 
Fig, 9b. 


The satellite itself does not contain any store= 
and-forward equipment. The gateway stations on the 
ground each act as a local user to the satellite, 

They can all monitor the frequencies so can pick up 
any traffic targeted at themselves. Since the sat- 
ellite operates in a duplex mode, they can all monitor 
the downlink when uplinking and can detect errors due 
to noise, or due to collisions and take appropriate 
steps. Since the orbit is known, they can determine 
mutual visibility and store messages until the target 
comes into a mutual visibility window. 


Each gateway station may act as the central 
store-and-forward station or as one of the regulars 
in its own network, and as long as the gateway is 
operational any station on the network has access to 
the network as a whole, Thus, it can truly be stated 
that the sky's the limit in amateur radio digital 
communications. 


Using the Networks 


The RTTY networks can be used in an identical 
manner to existing RTTY channels, It does not matter 
if they are Baudot or ASCII, CQ random, or point-to- 
point (autostart). Communications take place in a 
conventional manner. The use of NCL only becomes 
necessary if a message is to be stored in or retrieved 
from a computer, The location of the computer also 
does not matter, The user of the packet network will 
usually have a dual processor system, as shown in 


Fig, 10. The Terminal Interface Program (TIP) may or 
may not be part of the main computer. The TIP can 
In the 


operate in two modes; monitor or terminal, 
monitor mode, it can pass every packet it receives 

to the main computer. The destination of the packet 
does not matter) this mode is a good debug mode for 
testing the TIP, as well as providing a level of con- 
fidence in the early days. Since the packets may or 
may not be complete messages in themselves, the out- 
put of the TIP may or may not make sense. In the 
terminal mode, messages only addressed to the user 
will be output by the TIP, 
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If the TIP is a stand-alone board, having an 
RS-232-C interface, it can be connected to a ter- 
minal device and used as a dumb packet terminal, 

A dumb packet terminal is a terminal that can send 
and receive packets,, It contains the basic low=- 
level software to format a packet for transmission, 
and acknowledges reception of, and unformats, a 
received packet, Such a stand-alone board, micro- 
processor based, is a low--cost introduction to 
packet techniques, There is, of course, no reason 
why the TIP function could not be performed in 
software by the host machine, apart from the ob- 
vious one that it may tend to prohibit the use of 
the computer for other purposes. An outline of a 
stand-alone TIP is shown in Fig. 11, The break- 
down shown for the TIP comprises a standard micro- 
computer, The control program is in PROM, the data 
storage area is in RAM, The more RAM that is avail- 
able, the greater the length of or number of packets 
that can be stored in the TIP. 


It is envisioned that the user will graduate 
from the monitor mode to the terminal mode pretty 
quickly. After the novelty of receiving packet 
transmissions has worn off, the unit will be switched 
to the terminal mode, Of course, the user may tem- 
porarily revert to the monitor mode at any time to 
check that the TIP is still operating after a long 
period in which no messages have been received had 
occurred, The user, via the terminal, or the host 
computer can communicate with the TIP by using NCI. 
In this way, the user does not really care about the 
mechanics of getting messages across. All he is 
interested in is the message, i.e., the high level 
protocols, The low-level protocols of exactly how 
and when a TIP goes on the air can be left to the 
minority of technical hackers amidst the ranks,, 


It is desirable that the same software be used 
in all the TIPs, The real world will, however, not 
be the same as the ideal world, The standard PROMs 
supplied with each TIP could be programmed with the 
station call sign as ***, These general call char- 
acters will respond to all call sign addresses which 
is the monitor mode situation, Thus, in use--at 
power up--the TIP would output a sign on message to 
the serial plot such as AMICOM TIP REV 3.6 QRA which 
would identify the network program protocol and the 
revision level, The TIP would then be in the moni- 
tor mode and the user would change to the terminal 
mode by entering :QRA: followed by the station call 
Sign (including general call characters (i.e., :QRA: 
G3ZCZ). Note that a call sign such as G3ZCZ/4X 
would be recognized as having the 4X prefix--not 
the, or as well as the, G3 prefix, 


One advantage of a separate TIP is that it 
tends to maintain the integrity of the network. 
Consider a network in which one new user a day 
joins in, Given the number of radio amateurs and 
the number computers in existence, that is not an 
unreasonable assumption, If each user has to bring 
up software and hardware at the same time in an area 
in which he has not worked in before, the probabil- 
ity of errors occurring, bombing or typing up the 


network, is high. The network could thus suffer from 
a lot of down time due to those newcomers not quite 
being able to access. If a standard board is avail- 
able, the software can be provided to drive the in- 
tegrated circuits on the TIP which will minimize the 
number of bad signals on the network frequency, If 
NCL is used to control the operation of the TIP, the 
TIP can be driven by any computer having a serial 
port, programmed in any language. 


Once messages begin to flow into and out of the 
TIP, some high-level control is desired. This high- 
level control forms the user interface to the network, 
not at rf, as in the case of the simple RITY network. 
Again, here a hierarchy is possible, The TIP can 
drive a simple terminal in the monitor mode or can 
interface a microcomputer with floppy disc capabili- 
ties for storing (and forwarding) messages. 


In a simple RTTY network, only one contact is 
taking place at a time, irrespective of how many sta- 
tions are taking part in the round table. 
network, only one packet is being transmitted at a 
time, but successive packets as received at one sta- 
tion need not be part of the same message. There 1s, 
thus, no reason why when two stations are in contact, 
packets originated by other stations could not start 
appearing in the network and some of those packets 
could be addressed to one or both of the stations 
already in contact. 


Consider for a moment the working of the TIP in 
its receive mode. The program must monitor the fre- 
quency and read the leaders of all the packets on the 
channel. Messages intended for the TIP's own station 
will be output at the serial port. What happens if 
the TIP has received a packet from one station, but 
that the packet was not a complete message? While 
the TIP is waiting for the next packet that will con- 
tain more of the message, a packet arrives addressed 
to the TIP but originated from Station B. Does the 
TIP reject it because the new packet will garble the 
message currently being received? 


If the TIP rejects it (by not acknowledging it), 
Station B may keep trying, thus slowing down the com- 
munications speed of the channel because its packets 
will be ignored by our TIP, yet are using up time 
that could be utilized by Station A to complete his 
message or by other stations to pass different traf- 
Pies If the TIP does not reject it, a computer 
(either the TIP or the host) has to have some way of 
recognizing the different origin of the packet and 
storing it in the relevant bit bucket. On the other 
hand, the TIP could send a busy packet to Station B 
and anybody else which means that they can either try 
again later, or wait until they are called back. The 
busy packet could contain a flag bit or byte or NCL 
word that instructs the calling station as to which 
of the choices to follow, The call again later tech- 
nique requires minimal software in the receiving 
program, but can increase the amount of traffic, as 
the calling station keeps trying for a contact and 
keeps getting try again later responses. The wait 
for mé to call you response requires some additional 
software in the receiving program to store a list of 
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In a packet 


stations to call and notify that the TIP is ready 
for a new message, There the tradeoff is TIP soft- 
ware complexity against network traffic load, 


Most disc-based BASICs (and other languages) 
have the capability to have more than one disc file 
open at a time. It is, thus, logical that a high- 
level protocol can be used when the TIP is used to- 
gether with a host computer to allocate space on a 
disc for more than one incoming message at a time. 


The user being interested only in the whole mes- 
sage does not care how many packets it took to re- 
ceive the message. The network manager, on the other 
hand, may have different interests and a distinction 
should be drawn between the requirements of the net- 
work user and the network manager, Once a whole mes- 
sage has been received, the computer can signal its 
owner accordingly. The multi-message arrival problem 
is also significant in the situation in a store-and- 
forward mode, where the packets are assembled into 
complete messages for storage purposes. 


Another situation that has to be looked into is 
the CQ call or rather the response to the CQ call 
Situation. One of the major advantages of packet 
communications is wnattended operation, A terminal 
can thus be programmed to respond to a CQ call so 
that a newcomer joining the network will have a 
response to his initial call. What happens if 20 
stations or so try and respond to the CQ call? If 
multiple simultaneous received messages are allow- 
able, a station can end up having several simul- 
taneous QSOs. An extreme example of this condition 
is the effect on the network due to the appearance 
of a rare DX station. Consider what could happen 
to the network if a rare DX station signs in or 
originates a message. 


Avid DX chasers spend a lot of time and money 
on working new countries. It is thus very likely 
that these avid DX chasers could leave their TIPs 
in the monitor mode and have custom DX capture 
software in their host computer. ‘hus, the appear- 
ance of a DX station can be detected if it origi- 
nates even one packet into the network. The result 
could be a pileup. Each of the DX chasers will 
originate packets aimed at the DX station. Colli- 
Sions will occur, due to the QRM, calls will be 
tried over and over again and the network will be 
tied up for a long time even if the DX station has 
gone QRT (possibly due to front-end overloading of 
his TIP software?) as the DX chasers keep trying 
for a message acknowledgement. Thus, packet com- 
munications software deemed workable with few sta- 
tions (initial net situation) may be less than op- 
timum in a wide area established operational network. 


Packet communications offer a revolutionary new 
means of passing communications to amateur radio. 
For optimum results, it is very advisable that the 
low-level communication protocols and the high-level 
software be well thought out, flexible, and easily 
adaptable to changing circumstances. 
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Extending Communications Range by 
Use of a Repeater 
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A city-wide radioteletypewriter VHF repeater link. 
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Fig, 2. Timesharing of a Communications 
Channel 
be Messages -- 


Message A is sent by G3ZCZ/W3 to WA3LOS 
B is sent by WB4JFI to W3ZM 


C is sent by G3ZCZ/W3 to WA3LOS 
Dis sent by W3IWI to K1HTV/3 
Eis sent by WA3LOS to G3ZCZ/W3 


With proper prefixes G3ZCZ/W3 and WA3LOS 
will not notice that the channel. is being 
shared by others during the times that they 
are not actually transmitting anything. 


Fig. 3. Extracts from the Q Code. 
Coda Question Answer or Advice 
QRA What 8 Your identification or call My cali sign is... 
siqn? 
ORL Are you busy? Yes. | am m use 
byl... 
ORM - Your transmissions 
are berng tn terfered 
with. 
ORQ Shall lspeedupto.... Yes. 
bauds? 
QORA Are you equipped for automatic Yes. 
aneration? 
QRS Shall I slow down to... , Yes. 
a bauds? 
ORT Signing off (log off), 
ORU Have you any messages for me? Yes, messages are 
from 
ORV Are you ready? Yes. 
ORX Will you wait? Yes. 
QRY What 1s my tum? Your tum is number 
OSG Send... . messages. 
OSK Can you operate full duplex? Yes 
QSL Will you confirm? Confirmed. 
QSM Repeat last message. 
QSO _ Message for... . 
Qsp Relay wae. 
OTA Cancel message to.... Cancelled 
QTC The messane is) Db, 
oi i Whats your adefress? My addressts...- 
O71 What is the correct time? ines... UTC 
QTX Log on. 
QUA Send me all new messaqes. 
Quc Who did the |:1st message i sent go It went to... , 
to? 
ORM Send me the message from... . 
C:'D8 The message to... , 
: 1$ for warded 
Glc May ! call... direct? Ves 
QJG Revert to message 
Mode (log off inter- 
QNo . active more), 


Nevative response 
or action. 


Fig. 4. 


Statement 


What is your call sign? 

What is my exact frequency? 
What is the frequency of ...? 
Does my frequency vary? 


Increase transmitter power 
Decrease transmitter power 
Speed up to... bauds 

Slow down to ... bauds 


Have you any messages from me? 


Who is calling me? 


Can you operate full duplex? 


Which frequency/channel will you 
reply on? 

Can you copy... direct? 

Change to channel/frequency ..? 


How many messages do you have for me? 
What is your location? 


Has the last message I sent been 
forwarded? 


tOSA: and :QRK: can form the basis for 


Basic NCL Dictionary 


Response (if any) 


yy call sign is ... 

our frequency is... kHz 
His frequency is... kHz 

Yes 

Your bit error rate is... 

I am busy now, please call me later 
Your signals were interfered with 


There is noise on the frequency 


OK 

OK 

Signing off from the network 

Yes, messages are from e xo . ss 

Signing on to the network (includes QRU by 
implication) 

I am busy now, I will call you later 

It is your turn to send a message to ... 


Your report is signal strength .,. 

Your signals are fading 

Your signals were mutilated (negative ack- 
nowledgement or not received) try again 

I cannot accept packets from ... stations 
concurrently 

I can operate full duplex 

Acknowledging correct reception of packet 

Repeat packet 

I can copy you directly 

The message follows 
Please relay to ... 
Send your reply via 
station) 

I shall reply on... 


. *, (gateway or repeater 


I can copy ... direct 

OK, I shall change to channel/frequency ... 
Repeat message or last packet 

Cancel message 

The character count is ... (used in RTTY 
messages only) 

I have... messages for you 

My location is ... 

Message was originated at (day, time) 
Send me all the new messages 

Yes, it has been forwarded to ... 


Send me the message from ... 

The message to ... has been forwarded 
This is a direct call to 
Reverting to automatic mode 
Negative acknowledgement 


eea 


Signal reports. 


:QSM: could be used to flag a message that has been pagsed via a store and forward 


repeater. 
:QSU: 
:QTA: 
:QUA: 
puter to another. 


can be used for routing control, 
is used by the operator to delete received messages from his system. 
can be used when transferring the function of network computer from one com— 


whereas :Q08P: defines final destination. 


:QDB: could form an intermediate acknowledgement when tracking the routing of a 


message through the network. 
eQOTC: 


Can be used to. find out if a2 station 2s .loggeéd on at any particular time. 


:QNO: is the standard negative acknowledgement to state that the receiving station 


cannot perform the desired operation; 


This figure contains an initial proposal for the NCL dictionary which wfll, 


be changed as NCL comes into use. 


i,e,, it cannot QOSY or ORS. 
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of course, 


Fig. 5, Linking of Baudot and ASCII Networks 


A ASCII Network User 
Baudot Network User 

AR ASCII Network Repeater 

BR SBaudot Network Repeater 


T ASCII/Baudot translator 


Fig. 6. <A Basic Digital Repeater 
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Fig. 7. Interlinkingof Networks 
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Fig. Fig. 9. Satellite Based Network 


garavelee 


(b) Cr) y 
a \s 9 


0 O-——(C)a (®) 


0-—_ <9 
*, ag ye 
J Oc 
Fie No 
ce) 
AMSAT PHASE m/w 


ons 
SATELLITE 
— 


° \ ve 
re) 
A distributed wide orca network using a satellite. This approach 
would solve niuny of the message transmission problems. For a message to 


go from a station in network A to a stution in network G it would hove to 
travel only through the satellite and hen be relayed to the other station. 
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Fig. 10. Packet Network Interface 
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Fig. 11. A Stand-alone TIP 
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NETWORK ARCHITECTURE AND PROTOCOLS 
FOR A WIDESPREAD 
AMATEUR DIGITAL COMMUNICATION NETWORK 


Douglas Lockhart, VE7APU 
29 Shamokin Drive 
Toronto, ON M3A 3H7 Canada 


In the last couple ot years’ the 
Vancouver Amateur Digital Communications 
Group (VADCG) programmable communication 
controller has been used in many areas ot 
the U.S. and Canada. As one oft those who 
worked on the development ot the board and 
its sottware, | am very pleased to see that 
it has gained tairly widespread acceptance 
in the Amateur Radio traternity. It was 
not so clear, a couple of years ago, 
whether or not it would be accepted because 
I t 
Amateur Radio at the time. my impression 
ot Amateur Radio then was that it had a 
great deal ot inertia or resistance to 
change. suta t the same time, like a 
nassive body, once it gets movingit has a 
large momentum. Now I believe that Amateur 
Radio 1s moving into digital 
communications, and nothing is going to 
stop it. We need only to guide it to. the 
best system that we can. And what is the 
best digital communications system tor 
Amateur Radio? I don t think that anyone 
knows. The design ot a commercial digital 
communication network costs hundreds of 
millions ot dollars. That's right! - just 
tor the design, not tor implementation. 


Yet, even atter all this expenditure, most 
commercial systems have thelr problems and 
detractors. So, 1n Spite ot the small 


amount of money that Amateur Radio will be 
spending on network deSign, we may still be 
able to come U p- witha 
Surpassing, commercial designs. With this 
in mind will outline the general 
philosophy of the system that we are 
working on 1n the VADCG. 


Firstly, we wanted a low-cost intertace 
to the network tor an end user. We telt 
that a uSer Should not need to have a 


computer just to access the network. For 


this reason, we deSigned, produced = and 
programmed the VADCG programmable 
controller. Ot course, there were many 


other good reasons tor going this way, but 
I am mainly trying to show the tunction ot 
the controller in the network. 


The network that we designed the board 
tor WasS not intended to be homogeneous but 
a network in which nodes would have 
ditterent tunctions. Some of the node 
tunctions identitied were: 


1. A ‘Terminal' or ‘End user’ node. 
Typicaily, someone with only a 
teletypewriter or video terminal, although 
a user accessing the network through a 
microcomputer would also qualify in this 
category (i.e. an intelligent terminal). 


1.30 


involved the use of techniques unused in 


system equal to, or 


2. A ‘Gateway’ node. A node which 


allows users on the network to access 
another digital communications = system. 
Examples: 

A gateway to the telephone 


system using an auto-answer/auto-dial Bell 
1¥@3-type modem. 
A gateway to a digital 


communications channel on a _ satellite. 


A gateway to the Local vht RTTY 


c hanrrel . 
= A gateway to another amateur 
digital communications network. 
Note that it a node is used to 


interconnect two networks which have the 
Same protocols, 1t should not be called a 
‘gateway’ because, in this case, the two 
networks are actually only parts ot one 
larger network. 

3. A ‘Repeater' node. Used to 
extend the coverage ot the network. 

4. A ‘Logging' node. To_- record 
activity on the network to satisty 


regulations as wella S_ for per tormance 
analysis. 
5. A ‘Host ' node. This is the 


Computer system attached to the network and 
1s uSually the system that the end user 
wants to use, It contains the programs and 
tiles that the user wantS touse, suchas 
editors, games, compilers, assemblers, 
tile-transter programs, tiles ot Swap-and- 
Shop intormation, mailing list, etc. 


6. A ‘Station’ node. Coordinates 
the operation ot the other types of nodes 
ln the network. Provides network Services 
and communication between the network and 
the end user, repeater, logging, gateway 
and host nodes. At present, the concept 
calls tor all messages to pass through the 
Station node, but this 1S not an absolute 
requirement inorder tor the station node 
to do its job. The station node provides 
the higher levels of network protocol that 
the simple end user cannot provide tor 
himselt because 9 £ the Limitations 1n 
Storage capacity and complexity in the end- 
user inter Lace. 


7. A 'Message-Swi tching'’ node. This 
1S a node which has’ Sutticient storage 
Capacity to be able to store messages and 
data tor an extended period of time. Such 


a node would be something like a 
computerized bulletin board system (CBBS). 
Intormation which could not be directly 
transmitted to its destination immediately 
could be lett here to b e- sent onward when 
the destination node was available. The 
communication network 1S a packet-Switching 
network and so hasS little storage capacity 
tor messages. Messages are sent’ through 
the network only when both the source and 
destination nodes are available. The 
message Switching node could have messages 
to be received by any uSer on request as 
well as messageS intended only tor a 
Specific user. 


AS you can see, the station node haS a 
much more complex task than any oft the 
other node types. Fur thermore, the station 
node becomes almost indispensable 1n a 
syStem designed to use it. Because ot 
heavy. reliance on this node, it should be 
backed upb_ y another station node irthe 
area or by a repeater node allowing 
communication to another area which also 
has a station node. The hardware tor this 
Station node shouldbe tairly reliable 
because it involves no moving parts. The 
station node being used b y 
example, 1S a three-card S-199 bus system. 
One card is a standard CPU card, another is 
a 64-k dynamic memory card -= both of these 
are standard s-10@0 cards which are readily 
avallable trom many Suppliers. The third 
card is a special I/O card which the VADCG 
has developed tor handling the special 
needs of the station node. The card has 
tour channels ot HDLC communication using 
the Intel 8273 chip and six interval 
timers. The interval tlmers are used to 
handle 1 ine tiineouts andt o simulate a 
time-of-day clock. The timers and the HDLC 
channels are ail interrupt driven using 1l6 
channels ot vectored interrupts provided b y 
two AMD¥9519 chips. Also using the 
interrupt structure is the power ftailure 
Circultry, the transmitter taul t-detec tion 
Circultry and the circuitry to detect 
sottware tailures or Loops. A tailure in 
any ot these areas will cause the CPU to 
enter a 
EPROM storage on the same card. This 
program allows up-line reloading otf the 
Station node sottware or down-line dumping 
ot the station node Software tor analysis 
ot sottware errors. Each channel has a 
choice of baud rates and can operate with 
either synchronous or asynchronous modems. 
A number of extra control lines tor input 
of output are provided to control external 
devices. 

Some of the functions. and services 
provided b y~ the station node are: 


1. Establishment and termination ot 
virtual connections between nodes in_ the 


network. 


2. Communication with the end user 
in plain language. For example, the 
Station node will provide an explanation ot 
why a virtual connection could not be made. 
It will anterpret and act on network 
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the VADCG, tor 


program contained inupto8 k ot 


commands Submitted througn a terminal 
keyboard. It will provide a list ot the 
status of other users signed onto the: local 
domain O fF provide a list of users in 
another domain, tor example. 

3. Drive a logging node to record 


the connection/disconnection ot the users 
ot the network giving times and dates as 
well aS usage statistics. 


4. Drive a repeater node so _ that 
the repeater will do intelligent repeating 
ot trames. Not all trames received b y- the 
repeater should b e repeated. 


levels of 
network 


5. Provide the higher 
protocol required tor an extended 
tor the minimum end user system. 


6. Make routing decisions and keep, 
dynamically, information on delay times. 
The routing system as planned willuse a 
distributed del ta-routing system allowing 
multiple paths for communication between 
Station nodes -= something like the ARPANET 
routing scheme. Routing decisions will be 
based on minimal delay time. Changes in 
delay times detected by a station node will 
be passed to ad jacent station nodes. New 
Station nodes in the network will be 
integrated dynamically and will be deleted 
when communication is lost. 


7. Communicate with non-end-user 
nodes in the network uSing concise coded or 
tormatted network commands’ suitable’ tor 
computer generation and interpretation. 

The above is not a complete list ot 
tunctions provided b y 
Others will probably b e incorporated as the 
system develops, but this list should give 
the idea of what the tunction ot the 


Station node 1S. 


It should be noted that the above s1x 
types of nodes are not the only types 
possible b u t' only the ones which we have 
ildentitied as being the most important at 
the present time. Most tunctions canb e 
identitied as belonging to one ot these s1x 
types, even though there may b e occasions 
where there is an overlapping of functions. 
See Fig. Lt which should help to clarity the 


relationship of the nodes. Each station 
node haS a ‘domain’ associated with it. 
The doma 1n 18S the set of nodes that the 


Station iS providing services for. The 
domain iS typically a geographical area 
such aS a city, but difterent station nodes 
may operate on diftterent frequencies in the 
Same geographical area. The lines between 
the nodes on Fig. 1 represent logical 


communication links at the data-link Level 
ot communication. Not all possible 
communication links are allowed. Direct 
communication is allowed only between a 
station node and another node type or 
between two station nodes. However, a 
repeater node nay be used as an 


intermediate node in this communication. 
Any messages sent between non-station nodes 
have to be routed through the station node 


the station node. 


1n each domain. To some, this may appear 
as a harsh restriction on the communication 
possible, tor, atter all, there nay b e 
nodes in the domain that can communicate 
directly because of thelr proximity. To 
answer this let's look at the advantages 
ot going through the station node and the 
reasons for communication withthe station 
node. 


1. Standardization of the radio 
Each node's equipment has to be set 
up to interface only with one point. This 
means that adjustments to the modem, power 
output of the transmitter, frequency 
adjustments otf the transmitter, orientation 


link. 


oft the antenna and various other 
regulrements for establishing a 
communication link have to be set up tor 


only one link. This avoids having a large 
amount oft coordination with various other 
nodes. Once communication is #stablished 
with the station node, no other concern tor 
communication with the rest ot tne network 
1S required. 


and directional 
link. No 
using a 


2. Low power 
antennas c®n bea used tor’ the 
rotator is required, even it 
directional antenna. 


3. Nodes which areo ut 
range anyway would have to go throujh the 
Station node. 


4. Nodes which were using a 
ditterent band would have to go through the 
Station node to communicate. 


5. Nodes which were uSing ditterent 
Speeds would have to go throujh the station 
node. 


6. Nodes which required protocol 
translation would have to go throujh the 
station node. More on this later. 


7. NodeS communicating outside of 
the local station node's domain would 
likely have to go through the station node. 


8. Ali nodes using network services 
would have to communicate with the Sta tion 


node. 


9. Establisinment and termination ot 
connections between nodes would have to be 
arranged through connection services in the 
Station node. 


The above considerations do not totally 
ruleo u t 
being able to have nodeS communicating 
directly on the same Channel as that ot the 
Station node when they areusing the Same 
Speed and not requiring protocol 
translation and are within communication 
range. The protocol would have tobe 
complicated to allow these two types of 
communication to b e 


Channel and yet allow coordination by the 
Station node. All I can Say is that the 
present software does not coordinate 


communications on the channel which d o not 
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of broadcast 


the channel-sharing advantages ot 


more 


carried out on the same 


pass through the station node. However, the 
Software does iynore al l addresses which 

have not been asSigned by the station node 

so that other digital communication can 

Share the channel. It would probably be 

more appropriate that these nodes uSe 

another channel t o r_ their communication as 
they appear to have little need otf the 
network. 


You are probably wondering how the VADCG 
programmable communications controller fits 
into this network architecture because most 
users otf the board are using software in 
the board which communicates directly trom 
one end user to another end user. Well, in 
tact, this software which 15 commonly in 
us@ waS written after the original sottware 
for the station node architecture had been 
written and waS already in us2 . The 
terminal~to-terminal sottware 18 actually a 
moditication ot the original sottware to 
get it to work in a station-less 
environment, In tact, the hardware was 
limited to 4k of EPROM and 4k of RAM 
because the higher levels of protocol were 
going to b e 
b y the host node. In Spite of the general 
usage ot the board for direct 
communication, it is still the intent of 


the VADCG to develop a network based on 
the station node concept. More circuits 
nave been developed, and sottware has been 
written for use in this type ot network 


recently. 


i shows, this architecture 135 
at the station node level but 


ASFi1g. 
distributed 


not at the lower levels. There are 
multiple communication oaths Detween 
Sta tion nates but only Single paths be tween 
the station node and other modes i1n 4a 
domain. 

The VADCG  boar,*! can b2 used in the 
terminal node, the repeater node, the 


fogj3 1ng node, the gateway node and the host 
node. However, 1t probably 1S not sultable 
for uSe in the station node due to limited 
memory and the fact that 1t 1S a_ single 
channel. With suitable programminj, 1 
could posSibly be used aS a type ot tront- 
end processor for the station node. The 
VADCG 18S developing separate hardware for 
the station node. 


PROTOCOL LAYERS 


THE PHYSICAL LAYER=Thisis the lowest 
level. It de talls the character istics of 
the physical communications intertace 
between the systern components. we are 


adhering closely to RS-232-C standards in 
the usé of connectors, o01in asslynmen ts and 
voltage Levels. But, inadcition to the 


RS-232-C serial intertace, we are providing 
a TTL-level paraliel intertace and a 2%-mA 
Current Loop inter tace ln order to 
accommodate the widest possible choice of 
end-user equipment. 


THE DATA LINK LAYER = This layer manages 
the error-tree transm1isSlon of trames over 
communication Links between nodes in the 


provided by the station node or 


system. Most conmunication networks are 
uSing a system very close to the HDLC 
Standard aS 1S the system that we are 
uSing. This protocolis thes ame asthat 
being used in the VADCG programmable 
controller for direct communication now. 
Unlike IBM'S SNA, which Supports only an 


unbalanced ver sionof HDLC, we are using a 
balanced version in which neither node at 
each end of the Link operates in Slave 
mode. Both nodes Share packet transmission 
and recovery reSponsibility. When this 
layer receives a trameinerror according 
to the frame check sequence contained 
within each trame, 1t requests the 
retransmission ot that trame and all 
tollowing frames. The reception of each 
trame 1s acknowledged, and it no 
acknowldyement is received, some 
transmission fault iS assumed to have 
occurred, and corrective action is taken. 
This 1S usually an additional request tor 
acknowledgement. It additional requests 
tor acknowledginent tall, then the Link 1S 
assumed to have tailed, and other 
cortetbkive action is taken. The protocol 
requires poSitive acknowledgment only atter 
every 7 packets. The establishment ot the 
link useS an initial connection protocol 
(ICP) an which intormation is exchanged 
between the connecting node and the station 
node. The connecting node passes a 
description of itself to the station node 
which keepsitina table tor the duration 
otthe connection. The station node passes 


an assigned data link address to the 
connecting node which 1S used by both tne 
connecting node and the station node tor 
the duration of the connection. The 
Protocol 1s halt-duplex, multipoint and 
uses a carrier-Sense technique (CSMA) to 


resolve contention on the radio channel and 


Improve throughput. The contention 
protocol used by the Station node is 


Slightly ditterent than that ot the other 
nodes ii order to give the statlon node an 
advantage when contending tor use oft the 
channel. This 18 done »Decause all trattic 
in the domain must pass through the station 
node. The station node is working tor all 
the othernodes. 


THE NETWORK LAYER ~- This layer provides 
services which transport data through the 
network to its destination node. Messages 
that are transterred between domains in the 
network require a tull network address and 
network tlow-control functions, This 
information is addedtothe beginning ot 
the packet as another block of intormation 
Creating what Icallatype 2 packet. The 
packetS cominjy [rom a Simple end user do 
not have this additional aintormation and 
are 1n atype 1 tormat. These services are 
provided in the station node but may be 
provided by amuiti-userhost node, The 
decision to support tyde 1 or type 2 
packets by a 
time ot initial connection. When type 2 
packets areselected, no translation of 
packets isdoneb y the station and the 
Inanagement or the destination source 
address fFiel is as well aS management oft the 
sequence saumber is lett to the host node. 


1.33 


host node 1S 1ndicated at the 


See Figs. 2 and 3 tor the layout otf the 


pac ke ts. 
The. tollowing is an explanation ot Fig. 4: 


packet passed to it 
(the data-link 


Atter recelving a 
from the next lower level 
level), the packet 1s translated into a 
type 2packet using tables kept in the 
station node. The packet may already be 
type 2 in which caSe this transiation 1S 
not necessary. The pac ke ti1s then analyzed 
to see what its destination is. It the 
packet 1S not for this domain, then it 1S 
routed back to data-1link control. The 
router uses routing tables kept by higher 
layers to decide what link the data should 
be torwarded on. It the packet is tor this 
domain, then it is either for network 
services or for another node 1n this 
domain. It itis tor another node in thls 
domain it is translated to type 1 i€ 
necessary and passed to thes data-link 
dayer. Ititis for Network Services,t hen 
lt is checked to See that 1t originated 
trom an end-user terminal. It 1t did, it 
means thatt h e data has been typed in usin 
English words and must be _ par sed and 
analyzed by Terminal Input Services before 
being passed to Network Services for 


action. 


As a@€result of the commands received by 
Network ServiceS, Network Services may have 
control messages of: 1ts own to send _ to 
Various opointsi n the ne Work. These 
control messages use codes suitable tor 
interpretation by a computer. 1% they are 
tobe sent to another domain, then they are 
sent via the routert o Data-LinkControl 
output. If they aretor this domain and 
have to be interpreted by an end uSer 
(Terminal) , they are passed to Terminal 
Output services which translates tne codes 
to suitable Englisn languaje sentences. 
The packet tormati1s translated tot y pe 
lt necesSSary vefore belngpassed directly 
to Data-1link Control Output , This 
technique has a couple of advantages, 
First, because a knowledge ot th2 details 
ot the characteristics ot the terminal 15s 
kept in the domain's stationnode, Terminal 
output Services has all the intormation 
avallable to dotancy tormattingo f the 
message to the terminal. It knows the line 
length, whetherthe terminal supports lower 
case, highlighting, go to xy, erase screen, 
etc. This iS not Known at the remote 
Network Service point. Secondly, the 
computer format is more compact than the 
torm put out by Terminal Output Services 
and so is more etticient at utilizing the 
longer communication channels. 


Note that for every command that can be 
entered in through a keyboard by an- end 
user, there 1S a corresponding coded 
command Suitable tor generation by a 
computer, Likewise, for every plain- 
language response to a command, there 18a 
coded (or tormatted) reSponse_ tor a 
computer program. This means, for example, 
that if there 1S a tiie-transter program 
running ain a host computer the file- 
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1 


transter 
connection 


program can establish a virtual 

with another node using the 
network commands, transfer data across the 
connection and terminate the connection 
without human intervention. Host nodes are 
capable of establishingmultiple virtual 
connections at the same time. 


DEVICE SUPPORT 


As mentioned earlier, the station node 
recelves and holds intormation ont h_ e 
contiguration ot each connected node. This 
intormation is passed to the stationa t 
initial connection. ! nN the case of a 
terminal node, this intormation contains 
details ot the device character istics and 
addresses in the node. When a connection 
is established between an appl ication 
progran and a device, the appl ication 
program can request the device 
characteristic intormation from the station 
node. On the basis ot this intormation, 
the application program can decide how to 
Commun ica te with this device or even it 1t 
1S Capable otf communicating with it. For 
example, suppose a USeF tried to uSe a 
full-screen editor program but had only a 
hard-copy ASR=-33 terminal. The application 
program Can send anerror message to the 
user and Jisconnect. On the other hand, 
Suppose the tull-screen editor program 
tound that it waS communicating with a 
video display, then it ~»uld need to know 
how many tines and columns were in the 
display, whether lower case was supported, 
whether nighlighting was supported, etc. 
The tull-screen editor would then be abie 
to Communicate with the video display 
etticirently. This exchange ot intormation 
binds the device and the application 
prog rani t successtul. There witli be 


commands available to the end user to 
dynamically change the device 
characteristic information atter connecting 
to the station node. 


SUMMARY 


I was hoping to be able to go Into more 
detail on the routing, device support and 
packet tormats in this paper put realize 
that each of these ought to be the subject 
ot a separate paper. 


The author teel that the’ station node 
concept ot network development otters the 
most tunction torthel east costio the 
ninimalL enduser. The specialization ot 
tunction In the system prevents the waste 
incurred by duplicating the same code in 
every node. As new functions and services 
become available, they are instantly 
avallable to all users ot the network. The 
routing decisions are made atthe _ station 
node level, and the network 1S distributed 


at this level. This appears to be a 
reasonable tradeoft because the routing 
code is tairly complex and maintains a 
large amount of network  intormation. 


Further:nore, there does not appear to be a 
Simple distributed-routing system in the 


literature that 1S workable tor the low- 
cost end user node. The many advantages 
that tne statiun avde otters appear to 
strongly outweigh the disadvantage ot 


having to rely on 1t. In any case, we will 


have to rely on something 1f we are going 
to get our messages relayed across tie 
sontinert reliadly, and Iam _ sure that 
Amateur Radio 1S going to have ItS own 
digital communications network operating 


across the continent betore very long. 
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Domain 1 
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Fi gure 1. Relationship between nodes in a sanple netvork. 


H= Host, S = Station, T = Termnal, G = Gateway, L = Logging, R = Repeater 
M = Message Swtcher ? = Unknow network or service 
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Fig. 2. 
PACKET LAYDUT (END-USER TERMINAL NODE) 
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Figure &. GENERAL DATA FLOW IN STATION NODE 


ON THE CARE AND FEEDING OF YOUR PACKET REPEATER: 


by 


Rank Magnuski, KA6M 
311 Stanford Avenue, Menlo Park, CA 94025 
(415) 854-1927 


This paper will describe the construction and functioning of the KA6M packet 


repeater, 
of service. 


and will report on the operational results during the first 10 months 
Since its initial turn-on in December of 1980, the repeater has 


been transformed from an experiment to a major Bay Area repeater serving a user 
group now approaching 30 stations. The repeater has been extremely important in 


testing new hardware and software, and in provoking 


amateur community. 


I. The KA6M packet repeater 


From Its initial turn-on in December, 1980, 
and through most of the Spring of 1981 the packet 
repeater was operating out of my residence in 
western Menlo Park, California, a location which is 
in the foothills which border the western shore of 
the San Francisco Ray. It was an experimental 
machine then, but could be heard well through most 
of the northern end of Silicon Valley, even though 
the power level was modest. The only station 
equipped to use it then was located in the same 
house, so there was never any real problem with 
signal path. Since then we have installed a couple 
of upgrades to the control software, we have used a 
better CPU card, increased the power level, moved 
the repeater up to a 700 ft. elevation, and 
Integrated its operation to be 100% compatible with 
the protocol used by the Vancouver Digital 
Communications Group’s terminal node controller. 
The repeater has changed from being a laboratory 
curiosity to a major Ray Area repeater heard from 
Marin/Berkeley to south San J ose, and the user 
community has grown from a couple of stations to a 
network approaching 30 users. (See the April, 1981, 
QST for the initial announcement on-the machine.) 


The KA6M/R repeater is currently operating on 
a simplex channel assigned (in the San Francisco 
Bay area) for non-voice use, 146.580 MHz., and 
transmits data at a speed of 1200 Baud. The machine 
consists of a 2-80 microprocessor, a Bell 202 
compatible modem, and a solid-state transceiver 
with power amplifier. 


The repeater hardware is based on STD bus 
cards. The STD bus uses 56-pin 4 1/2" x 6 1/2" 
card8 and is very popular for industrial process 
control applications. There are now” many 
manufacturers supplying cards for this bus, and the 
repeater uses the 2-80/CPU-2 card from M ostek, 
which costs about $395. The STD card is very 
compact, and does not have unneeded extra circuitry 
which is typically found on more versatile personal 
system CPU cards. A WD1933 chip was breadboarded 
onto a Vector STD board, and one additional card to 
control the transmitter is all that was required. 


A Bell 202 modem uses a mark tone of 1200 Ht, 
and a space tone of 2200 Hz. The modulation is 
AFSK-FM using unmodified voice-frequency rad lo 
equipment. The signal ig NRZI encoded, which means 
that each zero data bit causes a mark-space or 
space-mark transition in the carrier. It is 
difficult to explain to old-time RTTYers that 
“mark" and “space” lose their meaning in an NRZI 


interest in the area’s 


sys tern. The HDLC frame guarantees that there will 
be a sufficient number of zeroes sent so that bit 
timing and clocking can be recovered from the 
incoming signal. No start/stop bits are ever sent. 


The radio is an PT202 handheld transceiver 
with a 20 Watt power amplifier. Since this repeater 
runs simplex, problems associated with full-duplex 
repeaters (desense, etc.) are not encountered, and 
exotic remedies, such as duplexers, dual antennas, 
and so forth, are not required. 


The control software for the repeater is 
written in PASCAL/Z, a PASCAL which generates 
native Z-80 code instructions. Assembly language 
interface routines have been written to control a 
Western Digital 1933 HDLC chip. The software fits 
into two 2716 EPROMS, and 2K bytes of RAM memory 
are available for use. The repeater can store up to 
eight 128=-byte packets. 


Before giving any more details about the 
repeater, it would be worthwhile reviewing some 
concepts concerning packet repeaters. 


XI. Packet repeaters in Amateur Radio Service 
Radio 


into three major 
Time-divereity, or 


Virtually all repeaters in Amateur 
Service can be classified 
categories: Frequency-diversity, 
Space-diversity. 


A frequency-diversity repeater is a conventional 
repeater which uses two or more frequencies for 
input and output. 


A time-diversity repeater may use a_ single 
frequency for both input and output, but the 
signals are separated in time. 


A space-diversity repeater or on-channel booster 
relies on the spatial. separation of its input ad 
output channels. 


For digital data-communications work _ in 
Amateur Radio many variations on the above three 
approaches are possible!. In the frequency-diversity 
case , for example , we have 


Linear translators = Devices which take incoming RF 
within a specified band and retransmit that RF on a 
new set of frequencies. There is a one-for-one 
mapping of each input frequency to each output 
frequency. Data communications through the soon-to- 
be- launched AMSAT Spacecraft will use linear 
translators. 


Audio transponders = The incoming RF is 
demodulated, and the recovered audio signal is used 
to modulate the outgoing carrier. Most 2-meter FM 
repeaters are of this type. 


Digital transponders - The’ incoming RF is 
demodulated, and the resultant audio tones are 
converted to their logic '1' and logic "0" values. 
The digital signal is then used to modulate the 
outgoing carrier with the correct AFSK tones. Many 
RTTY repeaters use this technique; it discourages 
voice communi- cations. Digital signal regeneration 
may also be done at the character level, where a 
complete incoming character is received and_ then 
retransmitted with new tones and bit timing. 


In all of the above examples, input and output 
activity occurs simultaneously, with practically no 
time lag in retransmission of the signal. Such 
repeaters are termed “duplex” machines, because the 
information is going in two ways at the same time. 


In the time-diversity case there is local 
storage for packets or frames at the repeater site, 
and we can run the repeater in a “simplex” mode, 
i.e., transmitting and receiving the frame on the 
same frequency. The outgoing signal is completely 
regenerated at the frame level, and all receiving 
stations are presented with a uniform signal, 
independent of the condition of the original input. 


The primary function of a packet repeater, as 
with a more conventional repeater, is to extend the 
geographic range and coverage of fixed or mobile 
stations. A packet repeater, however, can be 
programmed to selectively repeat only those packets 
addressed to it, thus allowing the possibility of 
multiple repeaters on the same frequency, an 
advantage instead of a curse! In fact, there is a 
wide range of functions which can be programmed 
into a packet repeater, and we will discuss some of 
these options later in this article. 


The FCC currently considers a packet repeater 
to be in the same category as an ordinary voice 
repeater) and so it must abide by the rules 
governing voice machines. Thus, it must be in the 
repeater subbands, must ID with a /R, cannot be 
used on a simplex HF frequency, etc. 


Of the three or four packet repeaters 
currently in use in amateur radio service there are 
no two alike, and each of the different approaches 
has its own merits: 


Contention Protocol Repeaters = Each station 
transmits on the channel without regard to the 
activity of other stations. If a packet collision 


occurs, the station will not receive an 
acknowledgement for the packet, will delay for a 
random period of time, and then transmit again. 


Carrier Sense Multiple Access = Each station is 
able to sense the carrier of other users and waits 
until the channel is clear. Collisions will occur 
in this form of contention protocol, but less 
frequently than above . 


Time Division Multiple Access = Each station is 
assigned a time slot for its transmission. Not used 


by amateurs yet. 


Polling Protocol Repeaters - The repeater cycles 
through a list of active stations requesting 


traffic from each one. No collisions occur, but 
stations must respond to the polls in milliseconds 
and the poll list. must be kept short fqr good 
throughput. 


The trade-off in these different approaches is 
channel utilization vs. centralized control and 
coordination. The tighter controls lead to better 
throughput, but the penalty is dependence on the 
functioning of a central station or on increased 
complexity of station equipment. Since the Amateur 
Radio service is a voluntary, non-professional 
operation, any scheme which depends on the 24~hour 
functioning of a single, central control station 
for all network users. should be looked at very 
carefully. A philosophy which adopts looser 
controls and multiple or redundant repeat points 
will probably prove more workable in the long term. 


The design of the local area network and 
repeater for each amateur community will probably 
be different and tailored to the needs of that 
community and subject to the technical preferences 
and biases of its designers. As long as the local 
net designers provide for future compatibility with 
whatever national networking scheme is adopted 
there should be no problem with variations of a 
protocol for a given region. 


Here in the Bay Area we are considering the 
possibilities of a two-repeater system, one serving 
the north Bay, and one for the south. The 
alternative is a single high-level repeater. We 
need further study of our expected traffic patterns 
and of the interconnects required to nearby cities. 
The higher the repeater the greater the range and 
coverage, and consequently the increased traffic 
and throughput delays. Lower level repeaters can 
handle smaller groups of users with better 
throughput, but connects to distant locations may 
require double and triple packet hops. 


Our design so far has stressed the ability of 
users to be able to do direct point-to-point 
connects to target stations if they are within 
radio range. This can offload some of the traffic 
from the repeater and allows’ stations to 
communicate with each other should the repeater go 
down. Note also that the 1200 Baud throughput is 
cut in half when packets have to be repeated, and 
is down to a third or less when two hops are 
involved. Some of our next experiments will be with 
two repeaters in tandem so that we can gain some 
experience in coupling two machines,, 


While were on the subject it would be 
worthwhile mentioning some devices which are very 
similar to packet repeaters but which have 
different names: 


Gateways - It is frequently necessary to 
convert a packet from one media to another or to 
transport a packet from one local net to another. A 
“local network” usually implies geographic 
proximity, a common. medium, and addressing which is 
unambiguous and at the lowest level of the protocol 
hierarchy. Each of the stations using a particular 
satellite channel might be a member of a different 
local net, and the satellite channel would be used 
to connect different local nets around the globe. A 
gateway would be used to convert a satellite packet 
to the format of another local net, say, the net 
consisting of all. the stations using the KA6M 
repeater. 
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Station Nodes « If a repeater participates in 
creating or dissolving a connection between two or 
more users, or if it has extensive information 
about the state of the network and provides routing 
directives to other repeaters, that device is 
normally called a “station node”. The — exact 
functions of a station node depend on the design of 
the network, but in general we think of it as a 
repeater which has been promoted into the first 
level of network management. 


Host Node - There are many different types of 
services which might be offered on a __ packet 
network, the most frequently mentioned one being 
electronic mail. Services such as that should be 
done by host machines on the network and probably 
should not be incorporated into a repeater. The 
hardware of a repeater should be simple and 
reliable, and should not depend on disk storage or 
other failure prone equipment. 


In summary, . becomes clear that with a 
programmable device we can implement many different 
levels of complexity and service in a repeater. 


III. Operational Aspects and Details of KA6M/R 


The 2-80 was an obvious choice for the basis 
of constructing a microprocessor based repeater 
system. It is a very popular chip, and some 
interesting high-level language support is 
available for it. The STD cards are small and 
compact, and it is extremely easy to wire a new 
board for testing ideas, 


The choice of the Western Digital 1933 chip 
needs more explanation. Quite a few manufacturers 
are now making HDLC/SDLC VLSI chips. Of the half- 
dozen or so available, only two have all the 
hardware required for easy use in an amateur radio 
environment. The special features required are NRZI 
encoding and an on-board digital phase-locked loop 
for timing recovery. The two chips which have this 
circuitry are the Intel 8273 and the Western 
Digital 1933. The Intel chip has a more elegant 
programming interface, but is slower and more 
expensive than the Western Digital unit. In 
quantity purchase the Intel part is about $35, and 
the Western Digital part is $25. 


The Bell 202 modem operates at the maximum 
Baud rate permitted on VHF, and works very well 
with voice frequency equipment. Also, 202’s are 
available from many different sources and can be 
found at surplus electronics houses. 


The 2-meter band was selected because it 
permits 1200 Baud transmission and radio equipment 
for it is widely available. Keeping the entry 
threshold low for packet users was an important 
part in introducing the service here. It's quite 
enough to ask someone to buy a new controller board 
and amodem. Requiring special radio equipment on 
top of that would be a burden. 


The repeater design assumed that the machine 
eventually would be on a mountain top, and that 
limited access to it would be the rule. Thus the 
design was kept simple, and minimum functionality 
was planned for the first installation. Virtually 
no manipulation is done on an incoming packet. The 
repeater allows arbitrary binary information to be 
present in the information field, and the only 
field which is manipulated is the address field. 


The repeater does not participate in the link-level 
protocol, and any acknowledgements or requests for 
retransmission must be done by the — end-user 
stations. Initially the repeater was set up to 
repeat a single packet with up to 256 bytes in the 
information field. That was changed, however, and 
it will now repeat up to eight 128 byte packets. 
Storing and repeating multiple packets in a single 
transmission is important for compatibility with 
the current VADCG software, and is required when 
packets are hopping down a chain of repeaters. If 
two packets are coming from opposite directions, 
one of the repeaters at crossover point must be 
able to store more than one packet. 


The address byte modifications which were 
adopted work as follows: the repeater will repeat 
packets which have an (address byte of hex 80 to 9F. 
In repeating the packet, the outgoing address will 
be the incoming address plus hex 20. Thus, repeated 
packets will have an address in the range AO to BF. 
This is the only alteration to the packet, and is 
otherwise an exact duplicate of the incoming 
packet. The address change is required so that 
receiving stations are not confused by a packet 
coming both from the sending station and the 
repeater. Stations wishing to direct connect may 
use addresses in the range 01 through 7F. The VADCG 
TNC software has been modified so that a station 
receiving a connect message adjusts its outgoing 
address to match the repeater/non-repeater range of 
the incoming connect message. So, a station wishing 
to log into the mailbox can do so directly or be 
repeated, and the mail’box will automatically adjust 
itself to the selection made by the operator. 


This addressing scheme has two major problems. 


First , it requires an _ individual to coordinate 
address assignments within a user community. 
Second , if the user population grows beyond the 32 


slots currently assigned to the KA6M repeater, 
something has to give. Several suggestions have 
been made to let the repeater dynamically assign 
addresses, but what we're really facing here is the 
tip of the iceburg with respect to some real 
serious issues concerning local area and nationwide 
network addresses and how to handle them. Some 
bandaids could be applied to the addressing 
strategy described above, but I think it would be 
better to face the more global issues right away. 


As soon as a packet is received the frame 
check sequence (FCS) field is checked, and if not 
correct, the packet is discarded. Next, the 
incoming address byte is checked for the right 
range, and if approved, the address field is 
modified and the packet is put on the outgoing 
list. When one or more packets are ready for 
retransmission and when the modem carrier detect 
signal has dropped to the channel clear state, the 
repeater turns on its transmitter and transmits all 
packets on the outbound list. 


The repeater has circuitry to sample both RF 
Carrier Sense and Modem Carrier Detect. Originally 
packet retransmission waited for a clear RF 
channel, but this proved unworkable in an RF jungle 
such as Silicon Valley. Now, the beacon will hold 
back if RF Carrier Sense is on, but packet 
retransmission will only be delayed by other packet 
activity on channel, or by tones which can fool the 
modem, such as RTTY AFSK. 


If at least 5 minutes have elapsed, and the 
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channel has been RF free for the last 30 seconds, 
then the repeater executes a beacon subroutine 
which transmits three 70 character packets. The 
beacon messages are very useful for testing the 
receive path of new packet stations, and for 
verifying that everything is in order both at a 
working station and at the repeater. They also have 


attracted lots of attention from hams in the 
community who have never before listened to packet 
transmissions. One uninformed gentleman described 


the beacon packets as “The longest squelch tail I 


ever heard”. 


Entering the beacon subroutine also triggers 
the CW identification. The hardware has separate 
control leads for request-to-send and transmitter 
on. The software currently turns the transmitter on 
and then toggles R-T-S on and off to produce the 
code required to ID. This procedure is not as good 
for packet stations can 


as the VADCG CWID routine, 

fire off a packet in the dead air time between the 
dits and dahs. The repeater, of course, is not 
listening. The VADCG TNC keeps Re TS: * ‘on 
continuously and uses Mark (1200 Hz.) for the dits 
and dahs, and Space (2200 Hz.) for the inactive 
time. 


The transmitter control card has some simple 
push-to-talk control, circuitry on it and. *a 30 
second watchdog timer. An absolutely foolproof 
watchdog timer is difficult to construct because it 
would have a hard time discriminating between 
normal program operation and a loop which 
periodically turned RTS and the PTT circuit on and 
off. Now it only catches a continuous RTS on state. 
One really needs two or three independent checks on 


the program to insure proper functioning. Failure 
of any one of those checks’ should reset’ the 
repeater. 

The FT202 radio has worked rather well 


considering its initial cost, and any similar unit 
would be Suitable for small to medium size 
metropolitan areas. Crystal controlled radios, in 
general, are ideal for packet service. They tend to 
have faster switching times than the new 
synthesized units. We are going to have to upgrade 
the unit here, however, because of the dense RF in 
this area. 


One of our more interesting findings is that 
the repeater has proven to be tremendously useful 
as a test tool for bringing up and checking out 
stations. The machine is there 24 hours a day, and 
by bouncing a packet off it you can quickly verify 
if your station is in order. The beacon messages 
provide a readily available signal source. The 
eight packets which can be stored represent nearly 
a third of a page of text, enough to’ trigger 
failures in T/O interfaces which might be prone to 
dropping characters. 


We also discovered, and this sounds’ really 
incestuous, that you can self-connect through the 
repeater. Due to the way the VADCG and repeater 
software and addressing is structured a station can 
make a complete round-trip connection loop to its 
own equipment. A line of text typed in at a 
terminal will come back to the screen via the 
repeater, and all error checking, re transmit and 
flow control logic is active during such a test. 
This is an excellent way for a personal computer 
system to exercise its software and test to see if 
there are any conditions under which bits and 
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pieces might be dropped. 


The repeater users have found that packet 
radio service is more demanding of their stations 
than originally expected. Modem programs that used 
to work fine at 45 or 300 Baud may not be able to 


keep up at the 1200-9600 Baud rate coming from the 
TNC. File transfers are expected to be 100% 
reliable, so the flow control mechanisms have to 


function perfectly in order to not lose data, 
Radios, modems and antennas have to be adjusted for 
optimum settings if the 1200 Baud 202 modem rate is 


going to be meaningful. We have reached the point 
where most of the pieces of our network are 
working, but a lot of fine tuning remains to be 
done. 


IV. Advanced Funstions for Repeaters 


The following are some of the ideas which have 
accumulated but which are not currently implemented 
in our repeater: 


Program bootstrap - A ground station is used 
to load the bulk of the repeater program. New 
features and functions, program corrections, 
routing tables, ete. could be maintained at a 
convenient host station away from the repeater 
Site. 


Changeable beacon messages = Special packets 
could be sent to load new messages of importance to 
the repeater users. 


Time of Day - A realtime clock. could transmit 


current time and date or GMT. 


Statistics =~ The repeater could keep track of 
the number of packets sent, packets in the last 
hour, number of users, total traffic, and so on. 


Diagnostics = The repeater could be put into a 
mode where it would send nearly continuous packets 
of some interesting pattern for a period of time. 
This would be useful for checking modems and levels 
and continuous reception of data at: a station,. 


Log list - Users like to know what stations 
might be monitoring and what stations were act ive 
in the recent past, The callsigns of the last ten 
connecting stations could be kept in a first-in 
first-out list, 


Multi-party conferences + The current point- 
to-point connections provided by the HDLC link 
level protocol do not allow real--time conferences 
or round tables. The issue, of course, is data 
integrity. Error checking, and retransmission must 
be done for each user plugged into the discussion. 
A smart repeater or station node might be able to 
arrange such a multi-way conference. 


Terminal-node repeaters - Any user who desired 
or was in a strategic location could program his 
TNC to act as a repeater in addition to the usual 
TNC functions, 


Role in larger network - The real mission of a 
repeater is to be a member of a larger national or 
international network. What functions have to be 
added to the program logic of a repeater to 
accomplish this is a subject for debate, and will 
hopefully be outlined in the near future. 


vy. Future Directions 


There are many possibilities for future 
development of repeaters inthe amateur service: 


Hardware ~ High speed, 48 Kilobaud UHF 
repeaters using direct digital modulation of the 
the RF, with no audio modems used at all. Decoding 
will be done directly from the IF strip. Repeaters 
with dual RF modules and selective control of 
frequencies and antennas . Spread spectrum 
transmission, with selective targeting of a 
repeater by changing the transmit hop codes. 


Software - Development of higher leve 1 
networking protocols in higher level languages such 
as PASCAL, C, ADA, FORTH, and others. Interconnects 
with other networks and CBBS’s. Development of 
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broadcast protocols which handle real-time 


conferencing and networking g:mes. 


It seems to me that we are only beginning, and 
that there is. still plenty of roon for future 
experimentation. 
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Voice Repeater for Local Area Packet 
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Abstract the Surplus modea selected diu not inanule 
Reyuest-to-senu ana clear-to-senu sijnals 
correctly. fhe Speaker auuio output of our 
In using the VANCG ‘Terminal Node two weter riys often was not flat across tne 
Controller (TNC) boara in the wWashinyton Fame of 22 mode Erejuencies (12uG dz to 
D.C. Metro area, meabers of the Awateur 2200 412) anu one tone or the other is 
Radio Research and Developuent Corporation attenuated. Transwtitters do not transmit at 
(AmRAD) have found it convenient to use an OfCe when Conuanded. Be 28. eeaay a: 
existing voice two meter repeater for packet involved, many williseconds could elapse 
work, Tnis paper addresses sojwe 0 £ tie before RP appears at tne anteuna jack, fhese 
probleus encountered wi th this a@pproaci) aau Ssuall probleas were surwounteu and wala 
some of the benefits tnat accrue, transuitctcea the first packet Oink our 

repeater. 
Introduction As soon as the secona user tried to 


In traditional two weter amateur radio 
voice COumunication, a two f£ reyuency 
repeater is eiuployeu to facilitate 
Conmunication between stations that are not 
inlineo f 
gutput of a receiver tuned to one freyuency 
is fed into a transwitter tuned to another 
freyjuency. A Carrier operated relay on tie 
receiver keys tne repeater transmitter. A 
G uplexer is usea to allow Sinjgle antenna 
to be used for vota receiving and 
transwittiny. Some delay is usually included 
on access and the transwitter rewains on for 
sowe Short tiwe after loss of inyut. The 
two £ requencies are seperated vy 905 Khz on 
two meters by ayreenent. AMRAD'S voice 
repeater operates on a freyuency of 147.81 
mhz transait and 147.21 mhzreceive. For 
several years it nas veen useu to sisare 
voice and data, often successfully. 


ra 


d 


wmeabers Of AHRAD veyan packet 
it was a natural evolution to 
use our esistiny voice re ,ea ter to 
experinent Olle A nunber of provleus 
surfaced that were not readily ayjyarent, 


_ when 
radio work, 


Proviaeus Encountered 


AMRAD packet rauio activities veyjan 
sill Moran (W4MIB) purcnasiny & VADCG 
TNC board and convinciny several others t o 
join hin in packet experiaentation, The 
actual buildinj of the boards went rather 
yuickly once the two critical parts (tue 
3273 Protocol Controller and 82598 USAR?) 
were procurred . Surplus wouens were obtained 
by our local club sioden buyer who searcied 
each haufest at the crack Of dawn to ovtaln 
Bell 202 devices for us to use on tue 
repeater. After several false Starts, tie 
modems were correctly hooked ty tie THC 
boards. Transmitter keyiny was a provlea i f 


with 


siynt distance of eacii otner,. The 
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recelve n4mi[e's packet, the next proble.wt was 


evident. Tue repeater was not cowing uy 
quickly enouji. The wachine would not cone 
up fast enouji to Caten tine HDLC pretrade 


syne or Elay. It Ccaujit tit uata and fraiie 
Check seyuence as well as tne clusiny Flay 
and CweID, but nothiny appearea on the 
receivers terainal screen. dank maynuski 
(KASS) Supplieu a £1x to allow RTS to jo 
high and turn ou the transaitter, then delay 
a while until tire repeater yot tie iuea to 
turn on and repeat. This siusle £ix allowed 
packet work to Oeyin in earnest and new 
users appeared. Juickly the uvenana for a vs’ 
packet every 8 vlinutes was evident. New 
users haa to have Something to tune up on 
witnout waitin; for tne niyjnely packet 
sessions. 


Douj Lockhart (VE7APU) haw Supplied a 
proyran to ao tine Qo packet and it was 
quickly Lnplenentea at the 2TH Of Terry fox 
(WB4S PI). Another provlei yuickly surtaced, 
we receiveu tne JST correctly must of tie 
time, wnowever, wien we lezt tae snack anu 
Came back Sume Ciwe later, tne screen was 
fFillea with last lines only. Tne JS? VacKet 
had six lines! wiere dia tne otier five 
lines jo? Sandy (eS145) Ccorcectly laid Che 
Cause to the repeater ID. tune repeater [5D 
fires every 19 minutes wien people are usiny 
the wacnine. but if no one uses tne waculne 
for five winutes or sv, the repeater I) will 
not fire until tue first eccess, Tue lon, 
ury spells of nv activity were ofrovoken every 
2 astinutes by the JST packet which firea the 
Feyeater [3 which sjuasucd tie first Five 
lines of the packet. Saadcy rfixeu tiis 
problea for us vy decreasin, tie voluwe of 
the repeater I) tone and lowerin; tie audlo 
frejyuency of the tone. Now all six lines of 
the repeater made it every 
time... eunless.....noise uapspeared on Che 
Yeyeater input at the save tiwe as tue S77 
packet, Tae JS pacnet is tiow a joou 
indication of tie Circuit comicion, If all 


receiviny all six 
conditions are 
paCKet 


are consistently 
lines of Cire QST packet, 
risiit For super terwinal to terwinal 
operatiois. 


o£ us 


interference iS a provlen in 
On a ShareG reveater. This Cowes 
in two foruws, intentional and accidental. 
Accidental interference occurs when two 
voice users think the packets (usually very 
short) ar noiSe wursts and transit away on 
top of tiie packets. Tney win in Ym voice 
O,eration if they Cavture the repeater Input 
with a stronj signal. One nigit wien a voice 
user appeareu in tne widule of @ packet O50 
between wb4MIb and ityself, we carried on tor 
2¥ winutes by iinterleaviny our packets in 
between tneir voice transiissions. we would 
wait until one vvoice user dropped his 
carrier and vefore the repeater uroppea we 
woulu bany tiie line Feeu key to fire off the 
packet. Finally tne voice users Cauyiut on, I 
think we yot away with it For sv lony 
because souwe reyeaters transitit a siiall tone 
when a@ user urops his transiiitter. Tuls tone 


Voice 


allows che receiver to know it 1S UK to 
transit. we Carefully explained jacket 
radio to the voice users wio nave never veen 
Seen ajalia on tne machine. 

Intentional voice interference (not 
really walicious) occurs when voice users 
just Cannot wait until tie packet 2350 is 


over. They sneak in a yuicKx call to their 
buddy between packets (Sawe trick we used in 
reverse in tie previous exaiivle). ‘salicious 


voice interference occurs when someone fires 
the autoyatch (tne jreat w»uyaboo of data 
people) in tne widule of a packet session, 
Channel sharing between packet ana voice 
Coulu work if users would let it. 
Design Provleus 

Two freyuency repeaters iwust be 

Coordinated with other users in tiie area, 


This is done tnrouji local repeater councils 
wii0Q @llot freyuency pairs. There usually are 
none to allot of) two meters, we already iad 
Ours and tius did not need a new allocation, 


Startup expense for two freyueacy 
repeaters is tigh. The Guplexer is typically 


$500. Problems jet worse from tnere, ask 
Sanuy, one of our control operators. 
Advantayes 

Sinyle £re.juency packet repeaters of 
the type constructeu by Hank (KAGM) suffer 
Frou a widden transaitter problea. In packet 
WOrKk, the wouead tones are sensed (carrier 
sense) and other packet users do not 
transit if they sense a modern is on 
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f reyuency at the time they wish to transmit. 
If a yiven station cannot hear all other 
peoyle on tne repea ter f requency, coll isions 
are Certain. A two f reyuency machine does 
not nave that probleuw as all users hear eaci 
otier (at least their todeas do, the 
software ignores direct packets when 
Connecteu). 


AMRAD users f£ind it convenient to 
develo» suftware for the TNC usinjt h e AMRAD 
two freyuency already available repeater. we 
are planning a sSinjle f re:jUenCy repeater, 
but the sortware Can we checked out before 
@einplaciny it at the new site. 


YThe jreatest advantaje t o 
already owned voice repeater i s startup 
Costs are already depreciated yprobavly. It 
is inexpensive if your already haveit = 
Serenalpity. 


using an 


Possible Enhanceuents 


If your yroup can affora tiie luxury of a two 
freyuency packet Cepeater , two ennancements 
can ve addeda t once, 


First, never allow ay voice, Use 
voice on your normal repeater to service tie 


data channel Jf reyulred, Accept no 
substitutes on the input. Only 1209 iz and 
220i) WZ tones, notiiny else. 

Second, allow wultiple inputs on = the 


repeater (pnone line, HF, etc.) and transmit 
all inputs on tire output, 


Other ideas need to ve tried. All 
ingut smodew tones of tine correct Ere yuency 
snoulu be re,ea ted, thus no “rejuest for 
repeat" wit is reyuired and hard addresses 
coved up to l27 users. A Logying Couputer 
Should wea@sure thruput and report to 
user Ssududl t ting G@ query. 


any 


Conclusion 


experience of AMRAD 
Shareu voice and packet repeater 
packet users who want to see 
being Sen t. in those packets. One new 
user is worth a few intentional voice 
jamers. The newcomers ask questions and 
Some eventually jet uyi n packet. The OST 
packet every eiyht minutes, in addition to 
actiny aS a circuit tester and new user 
board cCiiecker, attracts yuestions. It is 
easy to finda retired hai to watch the 
device at his home and insure it is well 
fed. ost peovle who use the ARAD machine 
Own Or use soe kind of computer, These are 
the type of people we need to attractt o 
packet data coimnuunications. 


It nas been the 
tha t a 
attracts 


what is 


new 


Formation of local standards 
in North Jersey Packet group 


Stephen E. 


Robinson, W2FPY 


47 Serpentine Rad. 
Ringwood, NJ 07456 
201-835-1152 


The successful introduction of digital 
packet communications to amateur radio 
depends not’ only upon the technical 
standards of the hardware and software of 
the packet interface, but also upon the 
resources and needs of the local amateur 


community. The planning of a local packet 
network requires examination of factors 
such as the available engineering talent, 


financial resources of both individuals and 
the packet group as a whol e, and 
pre-existing user equi pment. 


The introduction of new modes of 
communi cat i on to amateur radio is_ not 
without its history of birth-pains and 
trauma. The most common difficulty is 
redundancy with pre-existing modes. Single 
side band was in direct competition with AM 
for HF activity. Similarly, FM operation 
was at first rejected by those using AM on 
thr VHF bands. Today, NBVM lacks broad 
support because it has only marginal 
advantage over the existing, successful 
‘hike. Highly specialized modes such as ATV 


have no counterpart, and are assured 
continuity despite their cost of entry. 
Amateur ratel lite activity, EME, meteor 


scatter , auroral propagation, and microwave 
operations are currently pursued by _ most 
amateurs on the basis of the challenge they 
pose rather than their value as a means of 
communication. Extrapolating this 
comparison, packet radio communication 
augments, but is nonetheless in direct 
competition with RTTY as well as with the 
phone and CW traffic networks. In this 
approach to the formation of a local packet 
network , we will take advantage of the user 
support of these modes rather than attempt 
to compete with them directly. 


Packet radio could probably survive at 
its present level of activity without 
participation of non-technical users. If 
this is to be the case, it is unlikely that 
we will see the introduction of 
high-qual i ty commercial packet radio 
transceivers. On the other hand, by making 
it possible for the largest number of users 
to get started in digital communications, 
it would be possible to support the cost of 
sophisticated host equipment in much_ the 
Same way aS FM repeaters are currently 
Supported by their members. 


The development of local packet network 
standards presented here is founded upon 
the needs of the non-technical user rather 


than those of the avid experimenter. This 
network is designed from the bottom-up (end 
user ) rather than from the top-down 


(state-of-the-art technology) 
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We will start this design cycle by 
examining the minimum equipment necessary 
for digital radio communications. These 
are: a modem, a CRT or printing terminal 
(preferably ASCII), and a radio 
transceiver. According to the recent 


ARRL-sponsored survey (4) , approximately 11 
percent of radio amateurs’ are currently 
active in personal computing, and 4 percent 
are active in RTTY. Those with personal 
computers either have or can easily emulate 
a terminal. The RTTY users already have 
terminal 6, but requi r-e special 
consi derat ion because of their use of 
Baudot rather than ASCII encoding. Note 
that I have deliberately left out the 
requirement for a protocol controller 
because some of the features’ of packet 
communications (storage and forwarding of 
messages) can be implemented on the host 
system on a single-user-at-a--time basis. 


In an attempt to include non-technical 
users as well as experimenters in local 
packet radio activity, we have chosen a 


multi-layered approach to the network. The 


entry level to packet radio must be as 
simple and i nexpensi ve aSs_ possible, and 
should use pre-existing equipment. The 


lowest level must use the host machine as 
the protocol control ler . we call this 
entry level the "DUMBNET" because it is 
friendly to users having a “dumb terminal " 
and a 300 baud modem capable of half-duplex 
operation. DUMBNET wi 11 utilize 
asynchronous transmission format with no 
error checking, and will be similar to the 
now popular computer bulletin board (CBB). 
Several ports will be available into 
DUMBNETs these are: dial-up and one or more 
VHF or UHF FM repeater’ channels. In 
addition, by interfacing one of the  host’s 
radio frequency ports to accept Baudot code 
and 170 Hz _ shift, those amateurs’ with 
existing RTTY equipment could access the 
net. 


With the host acting as_ controller , 
traffic originating from these ports could 
be passed to other DUMBNET users, or to the 
more sophisticated true packet network 
users who aperate off the same host, but on 
different frequencies. Message traffic on 
the net could be conveyed down to all 
DUMBNET users by means of a periodic role 
call. This role call, running perhaps once 
every 5 minutes, would list the amateur 
call signs of all stations having pending 
messages. Retrieval of messages from. the 
host would be activated merely by sending 
one's cal 1 letters. In this way, those 
amateurs with dumb terminals will have an 
efficient way of visually “filtering” the 


presence of messages bearing their station 
as the destination. 


The next level up on the network, still 
using the same_ host as DUMBNET, i 6 
“SLOWNET”. Using true packet protocols, 
ALOHA f ashion, SLOWNET will interface more 
sophisticated users at minimal cost . 
SLOWNET wi 11 appeal primarily to those 
amateurs who have personal computers and 
can write or obtain software necessary to 
implement a simple protocol. Minimum 
equipment must also include, as in DUMBNET, 
a 300 baud modem capable of hal f-duplex 
operation. | n addition, the user must 
provide a computer interface for 
controlling the transmi t/receive function 
of his radio equipment. This does not 
represent major surgery to most_ personal 
computers or to the radio equipment. The 
modem transmit tones and TI/R switching 
functions can be connected to the FM 
transcei ver vi a the microphone cable, = and 
the received tones can be obtained from an 
auxiliary speaker (or headphone) jac:3i n 
most cases, there will be no "cosmetic" 
changes to the user’s transceiver. The 
packets will be in asynchronous (ASCII 
format with an appended error-detection 
code. 


Functionally, SLOWNET will not provide 
rapid communication for even a small number 
of si mul taneous’ users. It will however 
provide excel lent service for unattended 
message handling. The ability to send and 
receive personal messages and club 
bulletins will be the_ most attractive 
feature of this level of operation. 


Sti 11 using the common host computer, 
but operating at much higher speeds, will 
be FASTNET. This portion of the network 
has not been worked out in detai 1, but wi 1.1 
probably conform more closely with 
Standards developed elsewhere (1,2,3). 
FASTNET wi 11 use synchronous ASCII format 
with error-detection codes. Because of its 
speed, 1200 baud or higher, FASTNET wi 11 be 
a challenge to amateur technology and 
ingenuity insofar as design of the radio 


interface and modem. It is likely that 
existing commercial hi gh-1 evel protocol 
controller boards will be used for the 


digital portion of the user interface. It 
is hoped that FASTNET users will be able to 
dedicate their equipment full-time to the 
net. lf this is possible, then perhaps 
each user could eventually serve as a_ node 
in the net (all this transparent to the 


user )o 


The design goal of FASTNET is to provide 
rapid switching of a large volume of 
traffic over a limited coverage area. At 
this level, “packet-ragchewi ng" could be a 
real ity. 
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Highest on the network scale is the 
interface for packet messages entering and 
leaving the area of local coverage. On 
this level, compatibility with other packet 
systems wi 11 be essential. This interfece 
(OQUTNET?) may connect to amateur satel 1 ite 
transponders, HF (low-speed) packet nets, 
or to similar host machines on VHF through 
microwave, thus extending coverage to other 
areas. The choice of protocols, baud rate, 
frequencies, and modulation schemes. will 
depend upon the de-facto standards that 
will arise from today’s experimentation. 


In conclusion, this mul t i-1 ayered 
approach was chosen not only because it 
reaches the greatest number of users, but 
also because it contains a_ chronological 
sequence for painlessly bootstrapping up an 
operational packet network. The multi-port 
host described there does not yet exist. 
On-the-air tests will be necessary to find 
out if a small (S-bit) microcomputer will 
be adequate for real-time response to all 
inputs, o if a larger computer or a 
distributed processing system wi 11 
eventually be necessary. Since the host 
computer will define the character of the 
local packet radio network, the greatest 
development efforts will be placed here. 


I do not present this approach for use 
as a “standard” for local networking, but 
rather as an encouragement to individual 
approaches that best suit the local user 
community. Of course, standards will be 
necessary for packet communication outside 
the local region, but to prematurely set 
Standards for thre individual user may 
discourage experimentation and is contrary 
to the amateur spirit. 
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An Emergency and Routine Communication 
Network for Illinois 
Using Packet Radio Techniques 


Kichard W. Doering, WA6CFH 
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ABSTRACT 


Amateur Radio teletypewriter and computer 
communication may be enhanced using a packet 
radio network to time share network nodes, 
detect and correct errors, expand geographic 
coverage, and facilitate bulletin 
broadcasting. The network is based on a 
common channel carrier sensed multiple 
access 0 persistent protocol. Application 
of such an area packet radio network to 
emergency and routine communication if 
northern Illinois is discussed. 


INTRCDUCTION 


An excellent opportunity to enhance amateur 
radio communications for emergency and 
routine communication is now available to 
amateurs wishing to experiment with packet 
radio networking. Imagine, for example, 
approximately a dozen amateurs located 
within about one or two hundred miles of 
Chicago being able to carry on a half-dozen 
RITY conversations, seemingly 
Simultaneously, on a VHF frequency. If a 
heavy storm or tornado approaches one 
amateur, information concerning the storm 
could be automatically relayed to the other 
amateurs and the National Heather Service. 
General interest QST's, such as the ARBRL 
bulletins. could be broadcast to the group. 
All this communication between amateurs who 
have either Baudot or ASCII RTTY systems 
running at almost any speed with error 
checking and correction! Using an 
inter-city land or satellite network, these 
dozen hams could even communicate with other 
amateurs around the country or the world. 


This paper is intended to describe a 
Froposed local or regional packet radio 
network, with special emphasis On the 
advantages of applying packet radio 
techniques to RTTY communications in 
Borthern Illinois for emergency and routine 
communication. It is hoped that this 

article, and the others referenced, will 
tantalize the reader with the advantages and 
opportunitie § in experimenting and 
communicating using a packet radio network. 
PACKET RADIO * A REVOLUTIONARY COMMUNICATION 
NETWORK 


A Brief Tutorial Overview 


Amateur radio communication has several 
forms: 
Casual Conversation 
Point-to-Point Messages 
General Amateur Bulletins 
Emergency Messages or Warning Broadcasts 
Experimentation 
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Fach message has a priority, an orginator, 
and destination station or s ta tions. 
Messages are generally standarized in 
format, for example, the messages in the 
National Traffic system. . A protécol of 
message handeling proceedures is used to 
move tbese messages through NTS. 


Protocol 


Similarily, in this context of automated 
RITY communications and repeating (packet 
radio networking), a standarized format is 
used for the messages. Messages are broken 
into packets of' a convenient length, each 
having a standarized format (ref. 1). Of 
most interest in this generalized packet is 
the following header and trailer 
information: 
Address = destination station (with node 
Or zip code) sending station 
Priority * indicating message urgency 
Sequence number of Packet ~ used for 
message reconstruction 
Checksum = eg. Cyclic Redundancy Check for 
error detection 


A complete discussion of protocols and 
packet switching is beyond the scope of this 
paper. One reference (ref. 2), besides 
others referenced elsewhere in this [aper, 
describes protocol layers and packet 
Switching in a readable way. Like 
structured computer -rogramaing of 
subroutines, layering protocols allows 
increasing complexity to be implemented 
while keeping order and transparent 
operation. 


The protoce] (ref. 3) currently being used 
by the KA6@ "repeater" and the Vancouver 
Digital Communications Group (VADCG) seems 
to lack provision for priori-ty message 
designation and handeling. hecognition of 
emergency traffic would cause stations to 
temporarily reduce or suspend non-emergency 
traffic so that the channel would cot be 
overloaded. 


Network 


Fackets are transmitted from station to 
station through a network of nodes: 
Terminal nede - individual stations 
Kkepeater node = simultaneous repeating node 
(separate J/O freq) 
Store-and-forward node = (memory at node 
stores message for retransmission 
on the same freq.) 


The network and station protocol determining 
the permissible actions or transmissions of 
the rodes will be crucial to successful 
network operation (see ref.4). 


Interfaces for Network 


Since each message may be broken into 
several packets, each with sync, header, 
data, and trailer informaticn, to be sent at 
high Speed according to the network 
frotocol, a computer-based interface is 
needed for transmission and reception. 
While some amateur radio operators who 
already have a computer may sacrifice their 
time and computer for dedicated programming 
on a packet network, most amateurs will find 
a stand-alone interface board desirable for 
their terminal node packet radio use. This 
interface board, known as a terminal node 
controller (INC), will contain a 
microprocessor with some RAM, and a 
multiprotocol serial communications 
controller (a very smart UART). The TNC 
(ref. 5, 6, and 7) has EPROM-resident 
software to convert the terminal data 
(almost any speed, any code, ie. ASCII or 
Baudot) into the serial data following the 
network protocol. 


The radio used in a packet radio network 
should ideally have a short turn-around 
delay (less than 10 msec,) to reduce dead 
time between packets and reduce collisions 
(see ref. 4 for a detailed description of the 
radio requirements), Commercially available 
radios will require modifications to achieve 
low turn-around delay. Typical radios may 
be used, however, the 400 msec. turn-around 
time will reduce message throughput. 


Repeater or Store-and-Foruard Nodes 


A packet radio network will generally rely 
on multiple "repeaters" on the same 
frequency to relay packets, using the store 
and forward method- A _ store-and-forward 
node eliuinates the need for costly 
duplexers. Ey receiving packets, and 
checking the packet for agreement with the 
checksum, error detection may he performed. 
Errors are corrected (by ail nodes) by the 
lack of an ACK acknowledgement for a packet 
causing automatic resending, (In packet 
radio systems, where there is multiple 
contention for the channel, the transmission 
of a NAK for negative acknowledgement only 
increases collisions with subsequent data.) 


If only one "repeater" is to be used in a 
particular packet radio network, then the 
conventional simultaneous retransmission 
repeater may be advantageous. Such a 
conventional repeater may receive greater 
support by certain groups due to the 
Opportunity te repeat voice in additiot to 
packets, in some cases simultaneously. In 
this case the terminal nodes would ACK each 
other's packet through the repeater. A 
conventional repeater does limit the network 
in that multiple repeating, multiple routing 
is not easily supported. 


Hank Magnuski, KA6M has succinctly stated 
the attributes of digital repeaters (ref. 


€): 


1.47 


"The repeater serves to increase 
geographic range due to its advantageous 
location, it digitally regenerates the 
packet, providing all stations with a 
uniform signal, it selectively repeats 
only those packets addressed to it, 
allowing the possibility of multiple 
repeaters on the same frequency (an 
advantage instead of a curse!), and its 
beacon and packet-repeat facilities allow 
stations to do full-loopback testing, an 
invaluable resource in bringing up new 
equigpment and checking out 

hardware/sof tware modifications." 


Features of a Packet Network 


A packet radio network, like other forms of 
cooperation in our society, has much more 
utility as a system than the sum of its 
individual farts. Several important 
features of a packet radio netowrk over an 
ordinary serial communication link include: 
TDMA - Time Division Multiple Access 
Multiple Retransmission & Multiple Routing 
Error Checking 

Global or Selectjive Broadcasting 


IDMA & CSMA 


An attractive feature of a packet radio 
network is the nearly simultaneous use of 
the network by several commuaica tors. The 
transmission rate through the network is 
chosen to be 10 to 100 times the message 
generation rate. Time is divided between 
various users to allow for multiple access, 
hence the term Time Division Multiple 
Access. For example, most people type at 
about 20 to 40 words per minute and the 
Baudot tape transmissions are sent at 60 or 
100 wom. With a packet network operating at 
1200 baud approximately 6 to 10 different 
conversations may be on the network 
"simultaneously." 


To reduce collisions between packets, 
carrier sense is implemented and to reduce 
repeated collisions, a random delay is 
allowed to pass before re-try. Thus, the 
Montreal Packet Net (ref.4) uses a common 
channel carrier sense multiple access 
network with 0 persistent protocoi (CC CSHA 
0 Persistent), 


Multiple Retransmission = Multiple kouting 


With a large area Packet badio Network, 
multiple repeater (store-and-forward) nodes 
extend the radio horizon and provide for 
multiple routing capability for netwark 
availability. For such a multiple repeating 
network, a common channel store and forward 
node iS more appropriate than a conventinal 
two frequency repeater. The redundancy 
inherent in a large, multi-path network 
reduces network collapse due to a single 
node failure. 


At some time in the future the ability to 
efficiently reute packets along the best 
path (instead of all paths) will increase 
systen throughput, 


Error Checking & Correction 


For error reduction, packet radio net works 
generally use an acknowledgement (ACK) to 
Signify successful packet reception. If an 
ACR is not received for a given packet, the 
sending node continues to retransmit and 
wait for an ACK for a certain number of 
times- The packet receiving node ascertains 
error-free reception by comparing the 
checksum with the data in the packet, 
comparison may bedone in software or 
dedicated hardware, The CRC16 (cyclic 
redundancy check) error checking scheme will 
detect all errors less than 16 bits in 
length, and 99% cf longer errors (ref.4). 


This 


Error correction may also be implemented 
using a scheme Similar to error correction 
in dynamic RAM (Hamming codes). Additional 
bits are appended to each character allowing 
hardware reconstruction of the character 
without resending, if only a portion of the 
Character was corrupted by noise. 


Global Broadcasting 


Global broadcasting of messages to all 
network users is enhanced in a packet radio 
network since the act of relaying is 
automatic, error detection and correction is 
inherent, and broadcast messages may be so 
coded in the header. 


Examples of Packet Radio Networks 


Currently, several groups are implementing 
and experimenting with packet radio 
networks. AS outlined in ref. 1, the 
current major groups are: 


AREL ~ American Radio Relay League, 
Newington, CT 

AMRAD =~ Amateur Radio Research §& 
Development Corp., WaShington, DC 

AMSAT ~ Fadio Amateur Satellite 
Corporation, Washington, DC 

KA6M = Hank Magnuski et. al., San 
Francisco, CA 

VADCG ~ Vancouver Amateur Digital 
Communicatiou Group, BC Canada 

HAPN * Hamilton and Area Packet Network, 
Ontario, Canada 


A PACKET RADIO NETWORK FOR ILLINOIS 


Current N. E. Illinois Emergency Network 
For many years a Weather net" has been in 
operation in the greater Chicago area under 
the sponsorship of the N.E. Illinois 
Communication Association (ref. 8). The N. 
EF. Il. Network (NEIL), WB9AGH, uses a 
frequency of 147.06 MHz simplex to transmit 
weather bulletins and ARRL bulletins at 60 
wpm Baudot AFSK.~ Paper tape punched from 
the ueather wire is manually placed ona 
reader for transmission through a 250 watt 
kase station with an antenna at about 80 
feet. Several hundred stations contisaously 
copy the weather bulletins which during 
severe weather occupy almost all of the 
channel’s throughput. 


The appearance of microcomputers and the 
reat FCC deregulation allowing ASCII has 
prompted Robert Hajek, W9QBH, ARRL SEC, to 
consider semi-automated transmission of 
ASCII (in addition to Baudot). 


operation Skywarn (ref. 9) currently relies 
on voice reports of severe weather 
Situations to the National Weather Service. 
Since timly, accurate reports of severe 
weather, such as tornados, by on-the-scene 
observers, 1S essential in reducing damage 
and saving lives, an automated, error 
correc ting multigle access network capable 
of aboutoneor two hundred mile coverage 
seems to be needed. What a perfect 
application for a packet radio network! A 
trained observer initiates a report 
automatically broadcasted to the appropriate 
network terminals. 


Weather Telemetry 


The detection, tracking, and prediction of 
severe weather using atmospheric radiation 
from severe weather (ref. 10) could be 
enhanced through a packet radio network 
(ref. 11). The needed telemetry 1n this 
system is angle, probability (ie. 
intensity), and time of occurrence for the 
sferics pulses. Using several unmanned 
Stations scattered around the Central and 
Southern United States (the Rockies to the 
Appalachians), data could be collected, 
coded and sent every few minutes frog the 
monitoring stations uia a terrestrial or 
satellite packet radio link. Data would be 
collected at a central processor to 
triangulate occurrences, weigh data 
accuracy, and infer expected severe weather 
trends. This information would then be made 
available, via the network,, to any 
interested party. 


Other RITY & Computer Activities in Chicago 


The Chicago metropolatian area is home for 
many RITY enthusiasts, some of whom use the 
Chicago Area KTTY kepeater System (CARRS) on 
144.71 = 145.31 MHz. CARRS plans to have a 
mailbox system. 


Many computer hobbiests who are also hams 
live in the Chicago area. In fact, the 
Computer Bulletin Board System (CBBS) was 
first described by two Chicagoians: Ward 
Christensen and Randy Suess,WBOGPM (ref. 
12) 


Several other hams who have computers have 
commented to the authors they are 
individually developing a radio-accessible 
CBBS. 


In summary, there is the need for an 
improved automa tic weather data network, 
potential amateur support exists, and the 
time is right for packet. radio 
experimentation. In fact, one logical name 
for this network would be CAPEK - The 
Chicago Area Packet Emergency Radio Network 
since it will be a great leap (one meaning 
of caper) forward in message handling. 


Since CAPER may connotate illicit activity, 
a more acceptable name could be CAPS = 
Chicago Area Packet radio System, Whatever 
the name, we look forward to the formation 
of a packet radio network and offer, in this 
paper, suggestions for such a network, 


Desirable Improvements in N.E. IL Emergency 
Net for ASCII 


As mentioned above, the NEIL Net would like 
to enhance the 60 wpm Baudot transmissions 
by Offering a complimentary ASCII 
transmission. (It is assumed for economic 
reasons many stations will elect to retain 
their existing Baudot reception systems and 
will resist conversion to a packet radio 
network,) While surplus 110 baud Teletype 
model 33*s are available for a modest $100 
to $400 expenditure, not much is gained by 
transmitting at 110 baud ASCII to bardwired 
machines. For the present Baudot machine 
Owners, this money would probably be better 
spent on a packet radio terminal node 
controller board. (It is a well known fact 
that hams are cheap, or a% least are being 
squeezed by inflation like everyone else-) 


For the few hundred dollars an ASCII machine 
costs, the RITY ham is probably better off 
purchasing a terminal node controller if a 
packet radio network is available. En fact, 
the VADCG style TNC boards could provide 
even more utility and value for the HF RTTY 
amateurs, A straight ASCII to Baudot and 
Faudot to ASCII code and speed Converter, 
without packet generation, could be 
programmed if not already available. 


Briefly, the desirable improvenents proposed 

for the NE IL Emergency Net are: 

- Two way automated communication 

~ Wider area coverage, especially tothe 

West from where storms originate 

- Routine ham-to-ham communication to 
encourage packet node construction 

Uigher throughput, ie. emergency 
bulletins should be flashed at several 
times tae 60 wpm speed 

Priority queueing and handling of 
messages 

Bulletin koard service for bulleting and 
messages 

A regional packet radio network using 

protocol compatable with other area and 

the eventual worldwide HF and satellite 

AMSAT International Computer Network 

(AMICON) 

protocol compatable with the VADCG TNC 

board for simple amateur 

implementation, simplified software 

upgrade by EPROM replacement, and 

protocol officading to a dedicated 

processor/interface 

Simplified store-and-forward node 
implementatioa by amateurs attheir 
home stations 

Two way link with present Baudot users 
(features of the packet radio hetwork 
available through a standard, 
non-packet, Baudot AFSK VHF station) 

Cperation of the statewide Common Channel 
Carrier Sense Multiple Access 0 
Persistentcetwork On a 2M FM simplex 
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frequency using 1200 baud Bell z02 
compatable modems, 2H FM use would be 
initially encouraged to ease the 
transition topacket,ultisately 2.20 
MHZ may be better due to desense, 
specturm crowding, etc. 


Priority Queueing and Transmission 


The literature on packet radio networking as 
applied to amateur: and HDLC VLSI chip 
implementation seem to ignore priority 
queueing and transmission, While 
compatability with the Intel $273, 8274, 
Western Digital 1933 is commendable, we 
wonder if and how high priority packets 
should be handled? For example, a message 
"Tornado spotted at 3 PM in Southwest Suburb 
headed N.E. at 30 mph® should have priority 
over almost every other packet on a network 
and new low priority packets should not be 
introduced to the network until the 
emergency has passed. Possibly priority 
queueing is more appropriately implemented 
ata different protocol layer (ref. 13),ie. 
jJayer 2. Intranet, end-to-end rather than 
the layer 0. line control or layerl. 
Intranet, node-to-node. As an example, 
priority queueing of certain messages is 
used in the SITA worldwide airline 
reservation network. (ref. 14). 


and 


Individual Ham Station Implementation 


The above list contains advantages of packet 
radio implementation while at the same time 
illustrating the complexity of the network 
implementation. Fortunately, each ham does 
not need to be an expert computer progranmer 
and data transmission engineer,. Just stuff 
the INC printed circuit board witha 
pre-programmed EPROM, 8085 microprocessor, 
and the other support parts. Procure or 
build a 1200baud modem (TU for you RTTY 
fans) and use almost any terminal, 


Needed FCC Removal of Restrictions 


It would seem to us that the FCC should be 
called upon to remove several restrictive 
regulations to promote packet radio 
networks. 

- The requirement for a CW ID should be 
dropped as long as the cajlsign is sent 
in a common code eg. Baudot or ASCII 

The restriction on codes other than 

Baudot or ASCII should be dropped 
(excepting callsign) to allow 
synchronous data 

«~ The requirement of a control operator 
present at a station engaged in digital 
communication should be dropped to 
allow unattended acknowledgements for 
received messages, and radio accessable 
Computerized Bulletin Board Systems 


a ad 


CONCLUSION 


Packet radio networking will tremendously 
enhance communications in the Greater 
Chicago and Illinois area. Theneed for 
moce reliable, automated emergency 
communication 1S great, We look forward to 
receiving ccmments at the Computer 


Networking Ccaference and establishing IL 60546. 

diaglogue with interested amateurs. 9. Operation Skywarn, a voice network using 
repeaters on 2M and 220 MHz to relay 
messages to the National Weather Service 


REFERENCES of severe weather spotted by trained 
amateur radio operators. Since several 

1. Borden, David We, K8MMOQ, and Paul L. human interveners ase used to relay a 
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1981, pg. 28-30. 10. Fergus, Richard W., W9DTW, "Real Time 

2. Derr, Kurt W. “Packet Switching," Report Analysis of Atmospheric Radiation f roa 
No. EGG-2015, March 1980. Weather Fronts," NCC *81 Personal 

3. Magnuski, Hank, KA6M, “Packet Radio HDLC Computing Proceedings, reprinted in 
Protocol Notes, ® AMRAD Newsletter, September, 1198 1 AMRAD Newsletter. 
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in ref. 6 Doering, Sept. 1961. 

4. Rouleau, Robert, VWE2PY, and Ian Hodgson, 122. Christensen, Ward, and Randy Suess, 
VE2ZBEN, Packet Radio, Tab Books, Inc, WBOGPM, “Hobbyist Computerized Bulletin 
1981, catalog number 1345. Board," BYTE;, Vol. 3, No. 11, Nov. 1978, 
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June, July and August, 1981. 13. Cerf and Kirstein "Issues in Packet 
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7. VADCG Description in the Canadian Amateur 44. Schwartz, Wischa, Computer Communication 
Radio Federation Packet Radio Notes. Network Design and Analysis, 1977, 

8. N. E. Illinois Communication Association, Prentice Hall. 


Inc. WESAGH, P.O. Drawer H, Riverside, 
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COMPUTER-CONTROLLED MESSAGE HANDLING 


Russell D. Ward, Jr., WA4ZZU 
108 Louise Avenue, #B-4 
Nashville, TN 37203 


Although usage of computers in Amateur 
Radio is slowly increasing, some _ study 
Should be given to methods of promoting 
this utilization. This paper will show two 
methods of increasing computer message 
handling in Amateur Radio. These two 
methods are increased availability in the 
middle-term future and increased use of 
present capacity. 


AS was the case witn single sideband, 
two things hinder wideSpread use of 
Computers in ham radio: cost and 
complexity. Many hams are reluctant tobuy 
equipment costing aS much as ani hf 
transceiver for which they see no immediate 
uS- ang for which they have no training. 
Fortunately, both cost and complexity can 
b e jointly attacked. Cost and complexity 
are attacked both b y uSing equipment and 
Skills already available and alsob y 
dedicated microprocessor controllers. Most 
hams already possess the necessary 
input/output devices, a keyer and a TV set. 
These I/O devices combined with a 
transceiver form the basis of a Simple but 
effective computer-based station. The 
missing ingredient is the computer, which 
can b e avery Simple machinelt must 
translate cw to ASCII, format ASCII for the 
TV, and properly process the incoming and 
outgoing messages. The most important 
feature of this small computer is 
standardized software in ROM. The operator 


FIGURE 41, 


JoE HAM NEEDS Ail 
INS1OR DASNHBO LIME. 


rrr rer we we ee 
Dine a a ee as ee es 


FiguR& 2. 


WIOELY AVALABLE  Sincis 
VOLTAGE, 


using 


does not initially need much computer 
training and can take advantage of advances 
in program efficiency by changing a _ ROM, 
which can be reprogrammed by clubs or the 
AKRL for a fee.* A very basic, low-cost, 
microprocessor=-basSed mesSaye handler would 
be easy to construct, have an easily 
changed message format, and be compatible 
with any of the more powerful systems. 
Proliferation of these basic message 
handlers would lead to widespread use of 
Computers in ham radio traffic work. 


At the present time, there is not a lot 
of computer-assisted message handling. In 


order to steer clear of existing traffic 
circuits and simultaneously generate more 
traffic, work should be done to link 
several existing computer networks 
together. One group of hams per major city 


in which these existing phone-line networks 
are located could make their relay services 
available i.snnediately. A daily relay 
between existing non-han conputer »etworks 
would enlarj2 the networks, provide message 
volume, and give operational experience to 
hams. The experience gained by years of 
commercial computer network operation can 


probably be applied to the linking of non- 
commercial computer networks via Amateur 
Radio. 

*Ed. Note: The ARRL doesS not presently 


offer this service. 
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NOTES ON CLOSING SESSION 


David Engle, N6FTZ 
1063 Summerwood Ct 
San Jose, CA 95132 


These are questions and answers at’ the 
concluding session on October 17, 1981. 
These questions were asked of a panel 
consisting of: 

Dave Borden, K8MMO 
Doug Lockhart, VE7APU 
Hank Magnuski, KA6M 
Paul Rinaldo, W4RI 
Q@. Concerning configuration management, 
how do you enforce any rule set? This 


question concerned the AMICON proposal for 
the use of the L2 channel in the Phase 3 
satellites (reserved for packet 
communications). 

A. There waS no direct anSwer to this 
question, rather there was a general 
consensus that this could indeed be a 
problem. Further, this should continue to 


be looked at with some standards and 
possible enforcement mechanisms put forward 
for consideration. 


Q. Should the use of L2 be reserved for 
clubs or groups of people? Should it be 
reserved for gateways rather than 
individuals? 


A. There will not be any direct control of 
this function. It is not expected that 
many individuals will be willing to spend 
the money necessary to get into the channel. 
Thus, channel access will probably be run 
by groups. However, a caution was offered 
about elitism. 


Q. What is the mechanisin to communicate 
this emerging technology to amateurs? QEX? 
Orbit? 


A. Jens Zander, SMSHEV Suggested QST as 
the most available vehicle, especially if 
the European and worldwide community was to 
be included. Concern wasS expressed as to 


whether or not QST would handle technical 
matters of this depth. However, no 
worldwide alternatives could be suggested. 


It was pointed out that the IARU would need 
to be included in any standards setting and 
dissemination of those standards. 
Q. The potential problem of third-party 
message traffic was pointed out. 
specific 


A. Concern waS noted, but no 


ideas were put forward. 


Q. What is the 2-kHz L2 bandwidth, audio 


or rf? 


ssb 
It is 


A. The bandwidth is derived from an 
transmitter bandwidth circa 1978-79. 
4 kHz on center, i.e., +2 kHz. 


125.2 


Q. Is there packet 


lengths? 


any consensuS-~ on 


A. There is no consensus at present. This 
varies at present with the band being used. 
There are many variables to deal with. 


Q. Are there any plans to uSe_ spread 
Spectrum on Phase 3? 
A. No. Many problems eclipse this issue 


at present, e.g., legal, technical, money 


and other resources. 


Q. Has the issue of multi-level multi-~- 
tasking software needs been addressed? 


is addressed in terrestrial 
TNC board (thus 
Single-CPU 


A. This issue 
Systems by the Vancouver 
removing packet scheduling f roin 
multi-tasking. 

AMICON and 


Q@. What about routing 


terrestrial routing? 


A. This problem has been the discussion of 
several informal tmeetings. While no 
Solutions have been determined, the 
following points have been made: 


a. Routing problems are still vague. 
b. Call signs no longer can be used as 
@€ geographical locator. 
c. There is need for 
addressing, as follows: 
l. By geographical 
Local Area Net (LAN). 
2. within LAN, by call Sign. 
3. The device at the user Station. 
4. LAN addresses should be assign- 
ed centrally. 
5. The call sign table should be 
maintained at the LAN local level. 


2 to 3 levels of 


location to 


dad. Local Area Nets Should determine 
thelr own rules. 
e. Entry into the backbone network 


Snould be by invitation and will utilize a 
rigid set of rules. 

f. A one degree latitude by one deyree 
longitude grid system could provide a basis 
ov a global locator. It would also fit in 
the internet header. 

g. Another locator scheme was 
Suggested from the floor -=- the EA8EX 
system provides a 9.9 by %.6 Km world grid. 


Q. Are prioritieS going to be included in 
any protocol standards? 


A. It is an open point at this time. If 
it is needed it can be included. 


Q. IS there any industry/ham standards A. Yes. 


going on? 


A. The authors o f the ham standardsSare 


looking at industry standards as tney 
prepare the ham standards. 


Q. Is a set of standards going to be put 


forward, and if so will any connection be 
allowedir it meets standards? 
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Comment on setting standards: 


a. Standards are needed. 
b. Standards should allow evolution. 
C. Standards should start at levels of 
agreement wherever they may occur. 


311 Stanford Avenue 
Menlo Park, CA 94025 
October 16th, 1981 


Dear Packet Radio Enthusiast, 


Thanks very much for the letter of inquiry 
which you sent me. The response I've received to 
the initial publicity about the packet repeater has 
been very enthusiastic, and I have been deluged 
with requests from hams, both locally and from 


various points around the country, for more 
information about the repeater, for schematics, for 
listings, specifications, modems, proms, HDLC 


chips, Vancouver boards, and for talks at clubs. 
Needless to say, all this activity, plus continuing 
development on the packet hardware and software, 
has kept me very busy, and I apologize for any 
delay in responding to your letter. Let me bring 
you up to date on what has happened, or is 
happening, since the initial announcement of the 
repeater, which went on the air in December of 
1980. 


In the early months of this year, the packet 
repeater was operating out of my residence, and was 
still an experimental machine, Since then, we have 
installed a couple of upgrades to the control 
software, we have used a better CPU card, increased 
the power level, moved the repeater to 700 _ feet 
elevation, and integrated its operation to be 100% 
compatible with the protocol used by the Vancouver 
Digital Communications Group (VADCG). The repeater 
has changed from being a laboratory curiosity to a 
major Bay Area repeater heard from Berkeley to 
south San Jose, and the user community has grown 
from a couple of stations to a network of some 30 
users, The packet system here now has a mailbox on- 
line 24 hours a day, several on-line personal 
computers, and network links (courtesy of a 
commercial packet network) to the other active 
packet radio centers in Washington, Vancouver and 
Ottawa. We have also just installed an HF port on 
20 Meters, and are beginning some experiments aimed 
at establishing a _ connection with AMRAD in 
Washington and with equipment located at W1AW. 


Most of the original packet radio experiments 
were done in Canada (in part due to the Canadians" 
pioneering communications spirit, and in part due 
to less restrictive regulations up there), and 
three main centers were at work: Montreal, Ottawa 
and Vancouver. The technology employed by each of 
these groups differed, and each approach has its 
own merits. My thinking and ideas very closely 
paralleled the work started by Doug Lockhart, 
VE7APU, and so I can best report on what is 
happening with groups which have adopted HDLC 
(High-level Data Link Control) framing as the basis 
of their protocol. The HDLC/SDLC frame is a new, 
universally accepted standard in the _ data 
communications industry, and Doug and I feel it 
offers a good starting point on which to build a 
packet-radio network. As it turns out, groups in 
Washington D.C., Los Angeles, El Paso, Denver, 
Sacramento, Tuscon, and Hamilton have also taken up 
this technology, and it is likely that we already 
have a sufficient number of people using this 
technique that it will become the defacto standard 
in the amateur radio community. 


1.54 


It would be impossible for me to completely 
describe the protocol and equipment being used in 
this letter, so I will briefly cover some of the 
topics and give you some pointers on where to find 
additional information. As you might guess, this is 
a new area for amateur radio, and tutorial material 
and handbooks are not easily found. Many issues and 
problems remain to be discussed, and there is 
opportunity to make substantial contributions to 
the state of the art. 


The Protocol = The basis for our technology is 
the HDLC frame, which is simply a_ way. of 
encapsulating a series of bits into a message 
block. This type of message framing offers a high 
degree of error detection, data transpzerency, NRZI 
encoding, and a comprehensive set of standards for 


its use in a point-to-point protocol. Source 
documents for HDLC/SDLC and protocol are _ the 
following: 


IBM Synchronous Data Link Control, General 
Information, GA27-3093 (This manual is available 
through your company's IBM comp center or over-the- 
counter at most major IBM offices.) 


Advanced Data Communications Control Procedures, 
ANSI X3.66-1979 (This is the American standard or 
HDLC. Write ANSI, 1480 Broadway New York, New York, 
10018 for current price information.) 


For easier to get references, most recent 
books on data communications have chapters on "bit- 
oriented-protocols". These are some _ sources 
available: 


IEEE Transactions on Communications, COM-28 No. 4, 
April 1980 (Special issue on Computer Network 
Architectures and Protocols) 


11, pp 1301-1588, 


IEEE Proceedings,, Vol. 66, No. 
Packet 


November 1978 (Special issue on 
Communications Networks) 


Technical Aspects of Data Communications by John E. 
McNamara, Digital Press (See Chapter 19 on Bit 
Oriented Protocols) 


Communications Architecture for Distributed Systems 
by R.J. Cypser, Addison Wesley (See Chapter 11 on 


Data Link Control) 


NCC (Nacional Computer Conference) Proceedings, 
1975, AFIPS Press (Many excellent articles on 
packet radio concepts) 


Doug Lockhart's initial implementation of the 
protocol is a subset of the IBM SDLC standard. The 
enclosed notes document the type of frames used. 


HDLC Chips ~ Quite a few manufacturers are now 
making HDLC/SDLC VLSI chips. Of the half-dozen or 
so available, only two have all the hardware 
required for easy use in an amateur radio 
environment. The special features required are NRZI 
encoding and an on-board digital phase-locked loop 
for timing recovery. The two chips which have been 
used by amateurs are the Intel 8273 and the Western 
Digital 1933. The Intel component data sheet has a 
brief summary of HDLC framing. In quantity purchase 
the Intel part is about $35, and the Western 
Digital part is $30. 


Repeater Hardware = The repeater hardware is 
based on STD bus cards. The STD bus uses 56-pin 4 
1/2" x 6 1/2" cards and is very popular for 
industrial process control applications. There are 
now many manufacturers supplying cards for this 
bus, and the repeater uses the Z-80/CPU-2 card from 
Mostek, which costs about $195. There is no reason 
why S-100 280 cards could not be used for a 
repeater. The STD card is very compact, and does 
not have unneeded extra’ circuitry which is 
typically found on more versatile personal system 
CPU cards, A WD1933 chip was breadboarded onto a 
Vector STD board, and one additional card to 
control the transmitter is all that was required. 
The software, written in PASCAL/Z and assembler 
fits into two 2716 EPROMS, and 2K bytes of RAM 
memory is required. The repeater can store up to 8 
128-byte packets. The software and schematics will 
be available from me for a fee. Write or call if 
you are seriously interested in duplicating this 
equipment. The radio is~ an FT202 handheld 
transceiver with a 20 Watt power amplifier. Since 
this repeater runs simplex, problems associated 
with full-duplex repeaters (desense, etc.) are not 
encountered, and exotic remedies , such as 
duplexers, dual antennas, and so forth, are not 
required . 


The repeater serves to increase geographic 
range due to its advantageous location, it 
digitally regenerates the packet, providing all 
stations with a uniform signal, it selectively 
repeats only those packets addressed to it, 
allowing the possibility of multiple repeaters on 
the same frequency (an advantage instead of a 
curse!), and its beacon and _ packet-repeat 
facilities allow stations to do full-loopback 
testing, an invaluable resource in bringing up new 
equipment and checking out hardware/software 
modifications. 


The VADCG Terminal Node Controller - Doug’s 
group designed a low cost, 8085 based circuit board 
which uses the Intel 8273, and which has proven to 
be a very easy way to get started in packet radio. 
The hardware/software does an excellent job and 
many are in use here in SF. Most people ask “Why 
can’t I put this software onto my personal 
computer?” First, HDLC T/O interfaces are not 
commonly found on personal computers. Next, the 
VADCG TNC’ acts as a_ dedicated peripheral 
controller’ handling the radio link protocol, and 
thus off-loads this responsibility from the home 
system. The personal computer can go off 
reading/writing its disks while packets are coming 
in over the air, Handling two full-duplex I/O paths 
at high speeds is a non-trivial programming job and 
is above the skill level of many amateurs. The 
current program is about 30 pages of assembly 
language, and is not particularly easy to transport 
to other 8080/280 environments because of the 
interrupt handling required. We have managed to 
support a wide variety of different home systems 
with one software package, and an upgrade to the 
program requires replacing some EPROMs, not 
rewriting the software for 30 different DOS’s. 
Thus, for newcomers I would highly recommend buying 
a pair of TNC’s, as the cost of the bare board is 
only about $35. Total cost fully loaded is around 
$200. The software is available from several 
sources around the country. The TNC could also be 
programmed to be a packet repeater, with relatively 
simple modifications to the existing code. 
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Modems = The Bell 202 modem is a _ voice 
frequency 1200 bits-per-second modem which is ideal 
for radio work at 2 meters and which can now be 
found at reasonable prices through various surplus 
outlets, or which can be fabricated using EXAR 
chips or op-amps. This modem has become standard 
for amateur radio use at this Baud rate. At one 
time I had a good supply of these modems for $75- 
$90, but I’m totally sold out at present. There are 
as yet no standards for higher speeds or direct 
digital modulation of an RF carrier. This is an 
area which needs more experimentation. 


Newsletters = Our group does not have a 
newsletter, However , the following organizations 
periodically publish very fine newsletters which 
deal with packet radio: 


AMRAD, 1524 Springvale Avenue, McLean VA 22101 


VADCG, 818 Rondeau Street, Coquitlam, B.C., Canada, 
V3J 523 


Hamilton Area Packet Net, Stu Beal, Editor, 2391 
Arnold Crescent, Burlington, Ontario, Canada, L7P 
432 


Reference Material - Some recent articles and 
publications have addressed themselves specifically 
to packet radio in an amateur radio environment: 


Borden and Rinaldo, “The Making of an Amateur 
Packet-Radio Network.“, QST, Volume LXV No. 10, 
October, 1981, pp. 28-30. 


Rouleau and Hodgson, “Packet Radio”, TAB Books, 
Blue Ridge Summit, PA, ISBN 0-8306-1345-5, June 
1981 


Proceedings of the ARRL Amateur Radio Computer 
Networking Conference, Volumes | & II, October 16- 
17, 1981. Write AMRAD or ARRL. 


Networking - Most active packet users agree 
that the real driving force behind packet is the 
ability to interconnect geographical areas through 
networks. Electronic mail, digitized imagery, 
networking games, computer conferences and _ other 
unthought of applications remain to be explored. 
The next year should bring some heavy-duty activity 
in the areas of defining network protocols and 
standards, andmaybe even some interconnection 
between a few of the centers of packet radio 
activity. A conference to discuss these issues was 
recently held in Gaithersburg, Md., and from the 
number of people in attendance, and from the 
variety and depth of papers presented, it seems to 
me that a major new area in amateur radio has been 
opened . 


Thanks again for your interest. See you on the 
net. 


Best regards, 


Nente 


Hank Magnuski, KA6M 
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THE PACSAT PROJECT 


Den Connors, KD2S 
. PACSAT Project Manager 
Radio Amateur Satellite Corporation = AMSAT 


AMSAT has begun the desi and development of 
a new form of Amateur Satellite. The PACSAT series 
of satellite s ystems has as a design goal total 


global access by all hams to a_ store-and-forward 


packet radio message handler. 
Introduction 


_ AMSAT is ee the design and 
potas of a satellite-based experiment for 
advance igital packet satellite communications 
experiments. This system, called PACSAT, will 
use internationally-allocated Amateur Radio 
service frequencies. The PACSAT system will 
connect a grid of ground-base amateur 
radio local area networks in the United 
States and many other countries via a common 
store-and-forward acket repeater operating in 
the Amateur Satellite Barve: 


This paper details the reasons behind such a 
satellite. Followin the design concepts, a 
description of the entire system is given, anda 
list. of “technical parameters for each -of the 


defined subsystems is shown. The current 
outline of tasks and scheduling follows, with a 
description of the efforts of groups already 
engaged in the initial design effort. 


The PACSAT Concept 


The Amateur Radio communities in the United 


States and other countries are currently 
experimenting with digital networks on radio 
channels. These networks are using techniques 
already in place on the national telecommuni- 
cation networks known collectively as packet 
networking. 

Packet radio systems have a set of benefits 
unusual in present amateur radio systems. 
Large numbers of stations may share a common 
frequency, and use mui eiaeie access packet 
techniques to multiplex several sets of 
users in the time domain; very high spectrum 
utilization is accomplished i keeping all of 
these users on the same channel. A second 
benefit of the single shared channel 1s the 
ability to find all other users of the packet 
radio system. No searching of a wide 
band of frequencies 1S required; 
connectivity iS maximized. The need of multiple 
access techniques to detect successful 
transmissions yields a third benefit that, of 


reliable transmissions. Any message that arrives 


at destination has had its data integrit 
checked. This inherent reliability may wert 
open a series of possibilities for improving 
emergency traffic handling, one of amateur 
radio s most important aspects. 

As experiments continue on ground- 
:t77," packet radio local area networks, a new 


being considered to 
linking of both individual round 
area networks. The PACKet 
radio SATellite ( PACSAT ) system is designed 
to provide a store-and-forward digital repeater 
which is available to all groups aroun the 
world for fully global network coverage. The 
satellite peevides this coverage by occupying a 
low-earth orbit ( uEO ), which has several 
benefits. The close proximit of passage, 
relative to geo-syncnronous satellite, allows easy 
access, with good tink margins ". There are 
thousands of amateur radio earth stations 
that are already configured to operate on this 
class of satellite. Additionally proper 
choice of orbital parameters allows a 
sun-synchronous orbit, where passage 
satellite occurs at the same times each day, 

roviding an easy means of scheduling 

ransmissions. This orbit then provides both 
100, global coverage and very fair access, and 
creates a owerful new use of a well-known 
class of amateur satellite. 


of satellite is 
handle 
stations and loca 


2.1 


I'nere are several purposes for providing such 

a system in the Amateur Satellite Service. 
PACSAT will provide a wide-availability vehicle 
for advanced experimentattiom. and a prototype 
system for a new class of gatellite service 
involvin reliable transmission of data to remote 
sites an isolated users regardless of location. 
Several internationally-based organizations have 
expressed interest in just such oe ee ea and 
this gives AMSAT the oppurtunity o spear-heading 
a potentially major new push in low-cost satellite 
systems, much in consonance with the F.C.C. 
Charter for the Amateur Radio. Service asa 
"proving-grounds for new ee aay : The 
Volunteers in Technical Assistance (VITA a non- 
rofit firm dedicated to advancing the level of 


echnilogical expertise of less-developed 
countries, is ee aioe d pursuing the coordination 
of such vanguard activities and is working 


directly with AMSAT on the PACSAT development. 


Other benefits result from the use of digital 


techniques. Considerable improvements may be made 
to emergency communications, as_ reliable, ni gn 
availability links compatible with global mobile 


service requirements 
spin-off benefit for 
the new, 

community 


and ortable radio are 
rovided. Additionally, a 
MSAT itselff is the attracting of 
computer-aware members of the Amateur 


into the Amateur Satellite Service. 


A possible third set of benefits may be spun 
off the PACSAT system indirectly; the opportunity 


exists for designing new types of low-cost 
satellite launching and propulsion systems as a 
Pare: .-or this next generation of' Amateur 
spacecraft. 


Such a system would provide a number of 
functions. In addition to the primary use 
asa world-wide store-and-forward link, or 
"flying mailbox", the PACSAT experiment 
provide Me on regional linking Useandard LEO 
amateur mode ). As mentioned, both local network 
concentrators (gateways) and individual users 
could access the satellite. Finally the system 
would provide the mechanism for advanced testing 
of network systems concepts, hardware, software 
and protocols to be used by packet radio networks 
in the future. 


Other benefits result from the use of digital 
techniques. Considerable improvements my be made 
to emergency communications, as reliable, pee 
availability links compatiblewith global mobile 
and | ortable radio serwice reyuirements 
provided. Additionally, a spin-off benefit for 
AMSAT itself iis the attracting of the new, 
computer-aware members of the Amateur community 
into the Amateur Satellite Service. 


are 


A possible third set of benefits may be spun 
off the PACSAT system indirectly; the opportunity 
exists for designing new types of low-cost 
satellite launching and propulsion systems as a 
part. -of this next generation of Amateur 
spacecraft. 


Such a system would provide a number of 
functions. In addition to the primary 
as a world-wide store-and-forward _ link, or 
"flying mailbox", the PACSAT experiment 
provide real-time regional linking (standard LEO 
amateur mode). As mentioned, both local network 
concentratoré gateways) and individual users 
could access the satellite. Finally, the system 
would provide the mechanism for advanced testing 


of network systems concepts, hardware, software 
and protocols to be used by packet radio networks 
in the future. 


PACSAT System Description 


PACSAT is an extraordinarily corplicated 
system, rather similar in complexity to the Phase 
III spacecrafts. Fn. addition. “GO sac l1-oF the 


required satellite support subsystems on board the 
spacecraft, there are two experimental packages, 
each consisting of multiple uplink channels, 
common downlink channels, and modems 

coder/decoder link-access devices and control 
micrcprocessors with interfaces toa common 
satellite message processing unit (system control 
unit; .or-SCU).. As if that isn't bad enough, the 
rigid packet environment demands structured ground 
stations with all of the familiar hardware less 
the directional antennas, as we shall see), and 
erhaps several micropressors for handling both 
the sete stream and the automatic station control 
functions. The age of the microprocessor is upon 
Amateur Radio. 


To ease the burden of LS ae understand 
the whole system, PACSAT can be broken up into 


subsections, each with well-defined interfaces to 
other sections. A description of each_section or 
interface follows. Please note that, 


eeu the 
conceptual design has been finished, Many aesign 
groups. are hard at work coming uP with the 
specifications for their parts of he overall 
system, so that nothing below can be consrued to 


be the "final word". 
Spacecraft 


As mentioned, 


the orbit of PACSAT would be 
sun-synchronous, 


thar Le 


» appearing at the same 
time each oak UoSAT/OSCAR g has this type of 
orbit, and displays this property. Additionally, 
such an orbit guarantees at least two passes per 


day will be seen by ALL corners of the Earth. 


. The PACSAT satellite system may be broken 
into the spacecraft itself, and the experimental 


packages. The imberfaces: are. defined «to be 
spacecraft/ experiment and  spacecraft/ground 
station. 


Two options are availab/le mn a PACSAT 
experiments into space. The possibility of ridin 


the packages inside of a spacecraft ‘buil 
rimarilly Lor other ee exists, and allows 
the PACSAT design team to avoid the additional 


comp lexity 


of designing and building all of the 
required 5 


subsystems. AMSAT has looked (in 
particular at tne future launch opportunities 
available on the Conestoga-series of launch 
vehicles to be provided as a commercial venture ) 
Space Systems 0f America, _ Incorporated. SsI wil 
be launching payloads directly into low-earth 
orbit, providing a mechanism for direct injection 
of PACSAT into its final orbit without requiring 
on-board propulsion systems in the satellite. 


A second opportunity is more in line with 
AMSAT'S traditional method of designing _ the 
satellite "from the ground up", and will likely 

rovide man more opportunities for future 
auncnes. The Space eee eaeery: System (Space 
Shuttle) has the option of carrying into space 
sets of three “Get-Away Special" canisters, or GA 
cans. Although these cans have traditionally been 
reserved for inexpensive access for experimenters 
who did not require throwing their ex eriments 
into space, recent discussions with NASA have 
shown promise for using such a can aS a_ launch 
opportunity. A satellite would be placed inside 
the can, with a mechanism in place t0 allow the 
Shuttle crew to remotely ae the lid and push tne 
spacecraft into the void opefully after opening 
the Shuttle bay doors). 


This new two tremendousl 


Coie 
The 


opportunity has 
seful aspects: Eas can opportunities are 
$10 000) and potentially plentiful. 
drawbacks are the requirements of buildin such 
spacecraft as would berequired to fit into the 
can, and providing a propulsion mechanism for 
altering the very low orbit into whicn the Shuttle 
would place the unit, so that a,final, more stable 


orbit would be available. As it happens, _ there 
are active international AMSAT oe that are 
ver excited with the possibility of providing 
both spacecraft and propulsion. 


Th University of Surrey spacecraft design 
team (UoSAT) has expressed an interest in 
Conese ee their advanced low-cost spacecraft 
design and construction pO deere and view PACSAT 
as an excellent opportunity for using their 
integration expertise, and for providing a vehicle 
to carry other experiments of interest to their 
group. 


2.2 


The AMSAT/DL team at the University at 
Marburg, West eeu has been discussing the 
possibility of providing an innovative spacecraft 
engine whieh would be idea for such a craft as 
PACSAT = a steam engine, not unlike those first 
designed by Hero in ancient Greece. The mechanism 
for generating steam in space is not difficult, 
and innineging, sunlight on external water tanks 
could provide a large part of the ener required 
to heat the water. Heating coils electrically 
powered in the area of the super-heated steam 
nozzles would finish tne heating job. Although 
this concept seems a little far-fetched at first, 
calculations prove the amount of water required to 
alter the orbit of PACSAT is quite modest. 
Further, the ever-present problem of safety to the 
Shuttle crew is very much reduced by having 
spacecraft with extremely non-volatile fuels such 
as water! Gradual pushes "from the steam nozzles at 
opposites sides of the orbit will nudge PACSAT 
into its. final -orbit, and residual water could be 
used to furtner occasionally alter the orbit to 
keep it in a sun-synchronous plane. 


RACSAT Communications Experiment Package 


Each of two packages will contain a set of 
uplink and downlink channels with associated 
analog and digital hardware. Current designs are 
targettedfor ty ee four uplink channels, each 
dynamicall configurable with respect to data 
rate. One high=speed downlink channelwwill be used 
to support theuplinks, and to provide control 
over the smart ground stations. For an excellent 
review of the design effort for tne modulation 
techniaues and access modes of these channels, see 


the paper "“Moduiation and Access Techniques’ for 
PACSAT" by Phil Karn, which is included in these 
proceedings. 


Supporting these communications channels will 
be a series of filters, oscillators and 
amplifiers, along with microprocssors and buffer 
memory for channel control and support of link 
access propoe These processcrs, with. cies 
one or two channels per processor, will allow the 
demodulatiors chosen to be both adaptive in data 
rate and frequency agile. 


The set of packages will have a common system 
controller and main memory unit (RAMUNIT). The 
software to support the higher-level protocols and 
application programs to be resident in the SCU 
Will be loadable from the ground, a technique now 
common in tne Amateur Satellite Service... A memory 

ackage in the megabyte range is being 
investigated. 


Spacecraft/»xperiment Interface 


The spacecraft will provide the envvironment 
for PACSAT, including power, antennas and 
shielding from the extremes of space. A separate 
ocessor will handle tlle spacecraft's 

ousekeeping functions, an separate 
communications channels will be available for 
satellite command. Standard interfaces will 
define ndstations will be fairly 


complicated, reyuiring smart controllers to handle 
the re uirements of frequency agility in tne 
transmiters, and of linking, networking and 
presentation control. 

To allow users to ease into acket radio 
satellites, a radual upgrade pa% is to be 
provided for PACSAT use. A required piece of 


equipment will be the modem which will include a 

modulator, demodulator and pass-through path for 

transmitter push-to-talk and frequency control. 

This modem will be capable of operating as a 

stand-alone modem attached to one of the current 

(Hees of packet radio terminal node _ controllers 
NO). 


Operation of the TNC and modem pair with a 
standard set of 440-MHz transmitter and L-meter 
receiver will allow operation at 1200 bauds. 
Higher speed operation will require a separate 
rf deck, witn direct access to I} strips. peeds 
of wto YoUO bauds are planned. 


A final touch would bea 
specifically designed for tnis 
Sloan direct interface to 
ground-based internetworx linking. 


custom TN; 
system, and 
otner TNCs for 


It should also oe noted that conservative 
link margin calculations have shown that, with 
modest transmitter power on board the spacecraft 
and standard powere available to ground stations 
(around 25 watts,), the req uirement for having 
directional antennas 1S not mnecessary. Simple 
gain verticals like 5/8th whins on 440 and 2 will 
aegis be quite adaquate, especially at lower 
aud rates likel2U) bauds. 


Spacecraft/Ground Station Interface 


The PACSAT Project intends to use 
omnidirectional antennas on two of the most 
opular wvhf/uhf bands, in a mode which will be 
amiliar to Phase III users. Uplinks will be 
available at as ound 435 MHz, and choice of the 
proper channel will be made by the ground station 
controller, following the command requests of tne 
satellite. The common downlink will goes at the 
edge of the Amateur Satellite allocations, 
Sy echecreya| around 145.806 MHz for one package and 
45.994 Miz for the other. 


The modulation technique, synchronization 
requirements, encoding mode and related parameters 
are to be determined, based on experiments to be 
performed by two different design teams’ this 
spring. It isassumedthat either differentially- 
encoded phase-shift keying or minimum shift keying 
at rates in the 1200 to Y60O baud range, per atk 
adaptively availble, are the most likely 
candidates. 


The. link-level: access; protocols, that 1s, the 
addressing and error detection schemes are planned 
to be corp atible with the AX.25 Amateur acket 


radio re ocol_ standard. This’ -protocol. has 
already been implemented by several groups, and_is 
a de facto SAT standard for aJjl currently- 


planned packet satellite efforts. 


The network protocol will probably support 
AX.25 network-level protocol, and perhaps also 
less corplicated (and less’ reliable datagram- 
type" protocols as well. 


The memory interface between ground stations 
and the on board RAMUNIT will be little more than 
a virtual disk drive. with a very noisy connecting 


2.3 


link. On: top. of -tnis “protocol will ive: an 
applications program which will provide a number 
of message and file services. Experimenters will 
be provided with lower-level accesses to the 
system where such access does not’ significantly 
disrupt normal use of tne system. 


PACSAT Project Status 


The final conceptual review meeting was held 
in February 1985, and several of tne design groups 
attended, including representatives from both VITA 
and the University of Surrey. Many of tne more 
sophisticated concepts were thrown away to provide 
an easier target for scheduling. There will bea 


set of sub system design meetings at this 
conference, and further meetings to be held later 
this spring. Negotiations are currently underway 


with the candidate launch agencies and design 
Support groups. 


System design is likely to be completed early 
this summer, with deliverable items to be 
integrated and tested this bas Following 
critical design review meetings, spacecraft-ready 
subsystems will be prepared and snipped to the 
ee rhe agancy by mext spring. Such a 
sched ule would allow AMSAT to take advantage of 

ossible launch opportunities as early as late 
P 534 Slippages will be inevitable however, and 
more'realistic times will in general coincide with 
oe likelytarget launch dates, early 1985 to 
936. 


The project now has the support of twelve 
differennt design groups from four different 
countries, but Is Stil d in need of qualified 
hardware and software designers to help review all 
aspects of tne current design, and provide needed 
manpower with several of tne more important 
subsystems. PACSAT is an all-volunteer effort 
and will require careful evaluation by the genera 1 
user community during its initial phases to 
confirm design adage and provide guidance in 
the utility of tne various modes. It is hoped 
that this "system will not only provide many 
services which are forecast for the digital 
fututre of ham radio, but also create a whole new 
set of users and uses vet to be imagined. 
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Abstract 


This paper contains the latest draft of the 
AX.25 protocol specification. Inte is) The: “iirst 
ublic release of this draft. t#arlier drafts have 
een aiven to specific inviduals for comment and 
as a reference for software development. Changes 
Should be expected. Please check the AMKAD 
Newsletter for announcements of later versions. 


History 


Over the years there have been several proto- 
cols ae sauer for use at layer 2 of the TS Open 
System Interface Reference Model (OSI-RM) over 
Amateur Radio. The one system that has been in 
use is based on the IBM SDL@ protocol and it has 
been working as far as it went. One'of the imme- 
diate roblems that came up with SDLC was that 
its address field of SDuC is very limited (being 
one byte long causing problems if there are many 
amateurs on at'a time. 


ng to cone up with a protocol that every- 
one would agree to seemed like an almost impossi- 
ble task a year ago. What we at AMRAD decided to 
do was to go over the various protocols in use or 
available to the amateur, figure out the best and 
worst parts of each protocol and see if the proto- 
col could be "enhanced'" to work properly over the 
amateur radio enviroment. After reviewing the 
various protocols around and talking with eople 
in the computer networking industry, we decided to 
push the X.2 5 standard modified to allow a larger 
address field. At about this time, a group of 
amateurs in New Jersey were coming to the same 
conclusion. so about mid-June of 1982 the two 
groups got together and after two weekends came to 
an “understandin on a level 2 protocol. The 
most delicate meee of the negotiations between the 
two groups concerned the name to be given this 
protocol. In order to not aes on ary ones toes, 
it was decided to ces the protocol AX-25, which 
stands for Amateur X.20. 


The next step in the evolvement of AX.25 was 


that in October of 1982, AMSAT hosted a erectus 
of some of the leaders in amateur packe radio. 
AMRAD was at the meeting, along wit representa~ 
tives from TAPR, SLAPR. AMSAT., and PPRS. Three 


days of intense discussion followed. and an agree- 
ment was finally reached on a nation-wide compati- 
ble protocol. AX.25 was then modified to be com- 
patible with this new protocol (basically the only 
major changes were an additional extension of the 
address field, and the addition of a Protocol 
Identifier, or PID field). 


The rest of Ceeeap 
basics of the AX.23 leve 


erwill describe the 
protocol. 


AX.25 Layer 2 Protocol Specifcation 


This protocol conforms with the = Is0 
Recommendations 330Y, 43355 (includi gare 1&2) and 
6256 high-level data link control ( LC) and uses 
some terminology found in these documents. 


This protocol also conforms with ASI X3.66, 
describing ADCCP, balanced mode. 


. This pee is written to work equally well 
in either half- or full-duplex amateur radio envi- 
roments. 


This protocol has been written to work equal- 
lv well for either Point-to~zpoint connections. or 
connections made thru a largerdevice, such'as a 
metropolitan network controller(MNC). 


This protocol does allow the establishment of 
more than one layer 2 (iink layer) connection per 
device, if the device is so capable. 


2.4 


This protocol also follows in principle the 
CCIT? X.25 recommendation, with the exception of 
an extended address fiejd and the addition of the 
Unnumbered Information (UI) frame. 


Most layer 2 protocols assume that one large 


device (generally called a DCz#, or data circuit- 
terminating equipment) is connected to several 
smaller devices called a Di#, or data 


oe ane 
terminating equipment . AX.25 assumes that both 
ends of the link are balanced, thereby eliminating 
the two different classes of device. 


Frame Structure 


2 packet-radio transmissions are sent 
in small blocks called frames. These frames ar 
made up of smallerparts, called fields. Fig. 
shows. how the three types of frames are made up. 
Fig. lshows the frames in the same bit order that 
most packet articles show them. Unfortunately, 
this method has led t some confusion, Since tne 
least-s‘g nificant bit4 LSBis to the left rather 
than to the right, as most people would ordinarily 
assume. I am pointing this out early in this 
mass confusion as I 


Level 


aper to preven progress. 
ta er on, I will switch to a hopefully more under- 
standable way of showing the frame ans its compo- 
nents. 


Field Definitions 


called 
t..ese ear is made up of an 
or bytes), and serves a 


The frame is made up of several parts, 
fields. hach of 
integral number of octets 
specific function. 


Flag Field 


Since amateur packet radio is a bit-oriented 
protocol, the only way to tell when one frame is 
over and another 1s Starting for sure is _ to 
delimit each frame with a certain bit, sequence 
both at the beginning and the end. . This is the 
job of the flag field. A flag consists of a zero 


followed by six ones followed by another zero, or 
O1111110 0 (7b hex: Due to the bit stuffing 
mentioned above. the only time this sequence is 
ailfowea’ is at' the beginning and end of a 


legitimate frame. 
Address Field 


The address field is used to identify both 
where the frame came from and what the destination 
Of tt 2s. In the CCITT recommendation X.25, this 
field is only one octet long. This permits at 
most 256 users per level 2 channel, and since some 
-bits of this field were used for other purposes, 
the real number of users were about thirty per 
level 2 channel. Both the HDLC and ADCCP recom- 
mendations allowed the address field to be ex- 
tended, so we decided to extend the address field 
per their recommendations in the amateur version 
of X.25 to include the callsigns of both the 
destination and source amateur radio stations. 


The method used to extend the address field 
will be described shortly. 


Control Field 
The control field is used to identify the 


type _of frame and control several attributes of 
the level 2 connection. Dit 1S, (Ome OC USE: 1h 
length, and its encoding will be discussed in a 


following section. 
PID-Field 


The Protocol Identifier (PID) field is used 


only in information frames, and identifies what 


kind of layer 3 protocol, if any, is in use. Its 


encoding is as follows: 


M L 

5 S 

B B 

xxOUxxxx Reserved at the moment. 

xx01 YYIY AX.25 layer 3 implemented. 

xxlUyyyy AX.25 layer 3 implemented. 

111100 ce No layer 5 implemented. 

11111111 Escape character. Next byte 
contains more PID ne ema none 

Where: 

ie An x indicates a "don't care" bit. 

2 A y indicates all combinations used. 


Information Field 


The information field is used to convey the 
actual user data from_one end of the link to the 


other. I fields are allowed in only three tyes of 
frame;, the I frame, the UI frame and the FRMR 
frame. The I field can be up to 256 octets long, 
and should be an even multiple of octets long. 
Any information in the I field should be assed 
along the link totally transparently, exce Or 
any zero-bit insertion necessa EO revent flags 
from accidentally appearing in tthe ield. 


Frame Check Sequence 


The frame-check sequence is a sixteen-bit 
number calculated by both the sender and receiver 
of a frame. It is used to make sure that the 
frame was not corrupted by the medium used Ho oe 


the frame from the sender to the receiver. 
calculated in accordance with [SOQ 3309 (ibies 
recommendations. 


Bit: Stuffing 


In order to assure that the flag sequence 
mentioned above doesn't accidentially appear any- 
where else in a frame, as the frame is being sent 
it should be monitored, and if more than five 
contiguous ones are detected, a zero bit should be 
added between the fifth and sixth ones, eliminat- 
ing the oe. of a flag appearing in the 
frame er than where it belongs. The receiver 
of five ence. a zero, and more ones should automa- 
tically eliminate the inserted zero before passing 
the data on. 


Bit Order of Transmission 


With the exception of the FCY field, all 
other fields in an' AX.25 frame should be sent 
starting with the least-significant bit. in ae= 
cordance with HDLC Eee, the FCS should be 
sent most-significant bit first. 


Frame Abort 


aborted, at 


If a frame must be prematurel . 
be sent with 


least fifteen contiguous ones shoul 
no bit stuffing added. 


Invalid Frames 


Any frame consisting of less than 136bits, 
or not bounded by opening and closing flags, or 
not octet aligned (an integral n-umber of octets) 
enous be considered an invalid frame by the link 

ayer. 


Address Field Encoding 


The address field of all frames should be 
encoded with both the destination and source ama- 
teur callsi s of the frame. If a level 2 amateur 

repeater" is to be used, ar ore should also 
be in the address field. 25 follows the HDLC 
recommended method of eed: the address field 
in order to fit all Phi id seta into the 
address field. 


Basically, the way the HDLC address field is 
extended beyond one octet is to reserve the least- 
Significant bit of each octet for what is called 
an “extender bit". This bit is set to zero if the 
next octet contains more address field informa- 
tion, and is set to one if this is the last octet. 
To make room for this extender bit, the amateur 
ea call sign information is shifted one bit to 
the left. 


The actual encoding techniques for both non- 
repeater an? repeater operation follows. 


2.5 


Non-Repeater Address--Field Encoding 


If a level 2 repeater is not being used, the 
address field is encoded as shown in Fig. 2. The 
destination address is the call sign of the ama- 
teur radio station that the frame is addressed to, 
while the source address contains the amateur 
call sign who sent the frame. These call signs 
are the call signs of the two ends of a level 2 
AX.25 link only, not of any other station, such as 
the destination of a packet going thru an inter- 
mediary link. Those addresses should be ina 
higher layer, not layer e. 


Al thru Al4 are the fourteen octets that make 
up the two address sub-fields of the address 
field. aC destination sub-address is seven oc- 
tets long (Al thru A7), and is sent first. This 
will al the receivers of the frame time to 
check che destination address sub-field and see if 
the. frame is for them, while the rest. of the. frame 
is being received. The source address sub-field 
is then sent in octets A&% thru Al 4. Both of these 
sub-fields are encoded in the same manner, except 
for the last octet having the HDLC address ex- 
tender bit set. Since they are Letina at the 
same, only the destination sub-address will be 
Jutlined. 


There is an extra octet at the end of each 
address sub-field that allows room for. 3 
Secondary-Station Identifier (SSID) and three 
additional bits for future expansion. The SsID 
field allows an Amateur Radio operator to have 
more than one packet radio station. This is use- 
ful when an amateur wants to put up a repeater in 
addition to his regular station for example. 


Appendix A shows a typical AX.25 frame in the 
non-repeater mode. 


destination Sub-Field, kncoding 


Fig. 5 shows how an amateur call sign is 
placed in the destination address sub-field, oc- 
cupying octets Al thru A7. 

i Octet | ASCII, jBin.DatajHex Data 

, AL | W ylotuttty; AB Y 

j Ad | 4 pOTIITIOV | 038 | 

j A4 | J yVOTO100 | 94 

j AD r P jp LOOVITIO, 8c j 

| Ao | i j LOVT0010 4 Y2 

i; AT 1 pelLD” “PRRs LDOy 

Bat. posit tones 70543210 

Fig. 3. Destination Field kncoding 
Where: 

1. The top octet (Al) is the first octet 

sent Bort of like Bop ing: it. -off . the 


with bit UV of each 


to of the stack), 
Bet ee and bit 


being the first bit sent, 
ee the last bit sent. 


(low order or bit VU) bit of 
is the HDLC extenderbit, 

on all but the last 
field, where it is 


cae The first 
each octet 
which is set to zero 
octet in the address 
set to one. 


oe The bits marked "R” 
they may be used 
manner in individual 
aren t implemented, 


are reserved bits. 
in an agreed upon 
networks. Lf: “Lhe 
they should be se 


to one. 

4. The characters of the Seen a shourd be 
standard seven-bit ASCII pears case 
only) before being shifted le to make 
room for the extender bit. If the 
callsign is less than six characters 
LANS it should be padded at the 
eg ing end with ASCII spaces between 
ea vend of the callsign and the SSID 
octe 


Bs The SSID portion of the last octet has 
been intentionally left vague at this 


point, and is. lete up to the individual 
station to assign. e only recommended 
restrictio is to reserve the all-one 
condition (1111) for an all-call SSID in 


ne wants to reach an amateur but 
what SSLD that amateur 


case 
dooesn ‘t know 
operates under. 


Level 2 Repeater Address-Field #ncoding™ 

If a frame is to go thru a level 2 amateur 
packet repeater, there is an additional address 
sub-field added to the end of the address field. 

This additional sub-field contains the call sign 
of the repeater to be used. - This will allow more 
than one’ repeater to share the same rf channel, 
which has been a problem with the older protocols. 
If this field exists, the last octet of the source 
sub-field has its extender bit set to zero, indi- 
cating that more address-field data follows. T he 
repeater address sub-field is encoded in the same 


manner as tne destination and source address sub- 
fields, except for ost bit in the last octet, 
called the "dH" bit. The H bit is used to indicate 


whether a frame has been repeated or not. This is 
necessary to prevent someone from potentially 
receiving two identical frames, the one going to 
Pie repeater, and the one coming back o oon the 
eater. Fig. 4 shows how the repeater address 
-field is encoded. Appendix B is an example of 
4 Seonpleee frame on its way back from a repeater. 


Uctet ASCII i Bin. Data nex vata 

Pais Ti givitlut ag | 

| Alo | B A 1 NeNAUN 

| AIT | 4 jyttutuj toyovest) | 
Ale J yt ayororddr’ 94° 

| AID | + AH Y8 1188) } 

a ae “ 

| Ael | SSIL yj nakssLyty 

Bit Urder--> 76543210 


Fig 4. Repeater Address sncoding 
Where: 
1. The top octet is the first octet — sent, 
with bit VU being sent first, bit 7 sent 


last of each octet. 


2. As with the source and destination 
address sub-fields discussed atwws. bit 
of each octet is the HDLC address 
extender bit, which is set to zer 
all but the last address octet (a2) 
where it is set to one. 


Oe The "“k" bits are reserved just like in 
the source and destination sub-fields. 


4, The "H" bit is the has-been-repeated 
bit. It is set to zero on a non- 
repeated frame, and set to one by the 
repeater when the frame has been 
repeated. 

It should be noted that some of the advan- 

tages of this addressing scheme are mentioned in 
Appendix C. 


Control Field Formats 


The. control field as responsible: tor identi= 
fying what type of frame is being sent, and_is 
also used to convey commands and responses from 
one end of the link to the other Oo maintain 
proper control overthe link. 


control fields used in AX.25 use the 
CCITT ve 2b control fields for balanced operation, 
with an additional control field taken from AvUCP 
to allow connectionless and round-table operation. 


There are three general types of AX.25 
frames. They are the I formation frame (1 frame), 
the Supervis cy f’rame 45 frame and the Unnum- 
bered frame (U frame Bigs 5 shows the basic 


format of the control field associated with these 
types of frames. 


cae ee ee te ee ee ee em ee ee Om oe me om ee ee te ee ey Oe ee Om oe ee Oe oe Oe ow am om am ow we oe 


,Control Field Control, Field Bits | 
Type ie ech A a ee ee es ©, 

[I Frame | N(R) /P/B 1_a(s) 40 7 
> S Frame | N(H) [P/F] s Si Of 1] 
me eo en 
"ig. Control Field Formats 


2.6 


Where: 
1. Bit 0 is the first bit sent, Bre 7 Ls 
tne last bit sent of tne cont rol field. 
2 N(S) is the send sequence number (bit 2 


is Che. sot). 
pe N(R) is the receive sequence number (bit 
is the LOK). 


4. The vs ve . 
function bits, 
discussed below. 


5; The 
modifier bits 
discussed below. 


6. The P/i# bit is the Poll/Final bit. Its 
function is described in more detail 
shortly. 


bits are the supervisory 
and their encoding is 


"4" bits are the unnumbered frame 
and their encoding is 


Control. Field Definitions 


Information Frame Control Field 


A 11 I frames } ave bi t Y ef the control 
to zero. N(S) 1s the sender’ss send 
faces (the seéné seyuencenunber of this 
W(r) is thesenders receive seguence 
number (the Sequence number of the next expected 
received frame. These numbers are described in 
the section regarding flow control. 


field set 
seguence 
frame ) . 


Supervisory Frame Control Field 


Supervisory frames are denoted by havin 
bit JV of tne controlfield set to one, and bit 
of theiccontrol field. set to-zere:: © frames pro- 
vide  supervisor,! link cont rol such as_ acxnow- 
ledging or regueatins retransmission of 1 Trames, 
and link level window cont rol. Sinee 3 frames 
don’t have an information oe the s ander's send 
variable and the receiver receive eagle are 
not incremented for 5 Puaee 


Unnumbered Frame Control Field. 


Unnumbered frames are distinguished by 
having both bits U and lset to one. J frames are 
responsiblefor maintaining (control over the link 
beyond what is accomplished with 3s frames. T ney 
are also respons i ble for the establishment and 
tearing down of the link. uU frames also allow for 
the transmission and reception of information 
outside of’ tne normal flow control. Some U frames 
may contain information fields. 


Control Field Parameters 


SequenceNumbers and Va ria bles 


Every AX.25 1 frame shall be assigneda 
sequential number fromQto'7. This hill” aLtoW UP 
t) seven outstanding | frames per level ¢ connec 
tion at a time. 


Send State Variable V(s) 


The send state variable is an internal 
variable that is never sent. It contains the next 
sejuential number to be assigned tq the next 
transmitted I frame. This variable 1s updated 
upon the t ransmiss ion of each| frame. 


Send Sequence Number 4 (3) 


The send sequence number is found in the 
control field of all | frames. It contains the 
seyurence number of the | frame teing sent. a 

rior to the transmission of the'l frame, N(s) is 
updated to equalthe send state state variable. 


Receive State Variable V(k) 


The receive state variable is an inter- 
nal variable that contains the sequence number of 
the next expected received I frane. ‘his va ri able 
i. updated upon the reception oft an error-free l 
frame whose send sequence number equals the Ppfre- 
sent received state variable value. 


Received Sequence Number NCK i 


The received sequence number is in both 
Il and S frames. Prior to sending an I or » frame, 


this variable is 
received state variabie. 
ledging the proper reception of al 
and including N(Q)-1. 


(P/F) 


updated to equal that of the 
thus rey acknow- 
I frames up to 


Bit 


The P/F bit may be used =? all. types of 
Pp 


Poll/Final 


frames. It is used in a command oll) mode to 
request an immediate reply to a frame. The reply 
es this. p011 is cAdice ed by setting the response 

final) it in the appropriate frame. Only one 


outstanding poll condition per direction is al- 


lowed at a time. 
Control Field Encoding 
Information Frame Control Field 
The informa tion frame control field is 
encoded as shown in Fig. - “These: frames are 
sequentially numbered to maintain control of their 
passage over the link level connection. 


Cont rol Field Bits 


Fig. 6. I Frame Control Field 
Supervisory Frame Control Field 
The supervisory frame control fields are 


encoded as shown in Fig;. In, AxX.25, 5S frames 
are used only as responses to other frames. 
| Control Field Bits ; 765141321410, 
I" Receive Ready RR | N(R) {P/#] 00401 | 
\ Receive Not Ready RNR | N R jP/ iF Osa | Ce | 
| Reject REJ ; NCR j P/E | ss © i es i 
Fig. 7. S frame control Fields 
Receive Ready (RR) Response 
Receive Ready is used to do the fol- 
lowing: 
1. To indicate that the sender of the RR is 
now able to recieve more I frames. 
2. To acknowledge pies ay received 1 
frames up to, and including N(k)-1. 


Ss To clear a previously set busy condition 
created by an RNR command having been 
sent. 


It should be noted that the status of 
the other side of the link can be requested by 
setting the poll bit. 


Receive Not Ready (RNR) Response 


Receive not ready is used to indicate to 
the sender of I frames that receiver is temporari- 
ly busy and (cannot accept any more I frames. 
Frames up to N(R)-1 are acknowledged. Any I frames 
numbered ROR) and higher that might have been 
caught in between and not acknowledged when the 
RNR command was sent are NOT acknowledged. 


. The RNR concition can be cleared by the 
sending of a UA, Rk., Radon SABM frame. The P/F 
bit can be used within the KkNn frame to interro- 
gate the status of the other side of the link. 


Reject (RkJ) Respanse 


The re ject frame is used to reqyest 
retransmission 0 I f’rames starting with eae 
Any esr that were sent with a sequence number 
of N R)-1 or less are acknowledged. Additional I 
endeci to the ret ransmission of 


frame may be a 
¢k) there are any. 


the frame 1 


Only 
lowed in each direction at a tine. 
condition is cleared by the proper rece 
frames up to the I frame that caused the 
condition to be initiated. 


one rezect frame condition is al- 
The re done 

tion 0f I 
reject 


As with the other supervisory responses, 
the P/F bit may be used in the kJ frame. 


Zit 


Uunumbered Type Frames 


Unnumbered frame control fields are 
ei ther commands or responses. ‘This s tsnda rd fol- 
lows X.25_as much as possible. The only deviation 
from X.25 ig in the addition of the Unnumbered 
Information (UI) frame from ADCUP. X.25 is de- 
Signed to work with ig full-duplex systems with 
only one main device (Wn) and potentially many 
users (DTns). 


Amateur Radio packet systems differ greatly 
on both of these respects. Not only is Amateur 
Radio packet networking done in a half-duplex rf 
environment, but manydCu/DT# links many we shar- 
ing the same channel. Many amateurs have rejected 


the use of X.25 as a result of these problems. 
X.29 can easily be enhanced so that it will per- 
form properly over amateur radio. 
Fig. 8 shows the layout of U frames imple- 

ment ed within this standard. 

| Control Field ifype} Control Field Bits _ 

| | ee Go ales 4 5 2 Po | 

Set Asynchronous ,Cmd; 0 Ot | P | | 


j Balanced Mode=SABM 
| Discomnect-DISC jcmd}/ 010] P]o0o0] 11 | 


Disconnected ModejRes; OU UO ,P/#) 114 14 | 
| DM | i i j 

Unnumbered {Res} U1 14, F } 00111 4 
| Acknowledge-UA | | | | | | 
| Frame Reject-FrRMx | Res | foe yee ie ot A | 
| Unnumbered Bit} 000 (P/F, OO} 11 | 
j Information-Ul ;ner; i { | j 

Fig. 8. U Frame Control Fields 


Set Asynchronous Balanced Mode (SABw) Command 


The SABM command is used to place 2 
stations in the asynchronous balanced mode. “This 
is a balanced mode of operation known as [LAr 8B 
where JC#s and DTus are treated as equals, 


Information fields aren’t allowec in 
SABM commands. Any outstanding | frames left when 
the SaABM command is issued aKa remain unacknow- 
lecged. 


Disconnect (DISC) Command 


The DISC command is used to terminate a 
link session between two stations. No information 


field is permitted in 4 vis command f rame. Any 
outstanding I frames will reimain outstanding. 
Disconnected Mode (UM) Response 
The disconnected mode response is sent 
whenever the vDIs or DCs receives a frame other 


than a SABM while in a disconnected mode. Lt is 
sent to request a set mode command, or to indicate 
it cannot accepta connection at the moment. the 
DM response cannot have an information field. 


A DCs 
wi.l respondto an 
a DM response wit 


Unnumbered Acknowledge (UA) Response. 


The UA response frame is sent to acknow- 
ledge the reception ard acceptance”ota Jf “rame 
command. A received command is not actually pro- 
cessed until the UA response frame sissset.. An 
information field is not permitted in a UA frame. 


or DT# in the disconnected mode 
command other than. a SABM witn 
the P/i¥ bit set tol. 


Frame He ject_(Frak) Response 


The FRMX response frame is sent to re- 
port that for some reason the receiver of a COm- 
mand or information frame cannot successfully 
process that frame and tnat the error concition is 
not. correctable by ee as offending frame 
again. Typically this condi t ionw ill appear wnen 
a frame without an FUS error has been received 
with one of tne following conditions: 


i, The reception of an invalid or not 


implemented command or response frame. 


2. The 
information 
upon length. 


reception of an I frame whose 
field exceeds the agreed 


3. The reception of an Taproper N(R). This 
usually happens when the N(R) frame has 
alread een sent and acknowldeged, or 
when N(E) is out of sequence with wha 
was expected. 

4. The reception of a frame with an 
information field where one is not 


allowed or the reception of an U or S 
frame whose length is incorrect. 


When a CMDR or FRMR frame is sent, an 
information field is added to the frame that helps 
to explain where the problem occurred. This 


information field is three octets long and its 


contents is shown if Fig. 9 below. 

nformation Field Bits 
| eee eb ft Te OTe Ta 

O21 OO 6 34 Be 109 BT Oba DS 20 Oy 


on VCR) jC V(S) 04 Rejected Frame | 
1 14 Control Field | 


Page. 9 FRMR Frame Information Field 
Where 
ils The rejected frame control field carries 
the control field of the frame that 


caused the reject condition. It is in 
bits 1-3 of the information field. 


as V(S) is the current send state variable 
f the device reporting the rejection 
4bit tQis the low bit). 


or V(R), is the current receive state 
variable of the device reporting 
rejection (bit 14 is the low bit). 

4. If Wis set tol, the control field 


received was invalid or not implemented. 


Ds If X is set to 1, the frame that caused 
the reject condition was considered 
invalid because it was a U or S frame 
that had an information field that is 
not allowed Bit W must be set to lin 
addition to the X bit. 


6. If Y is set to 1, the information field 
of a received frame exceeded the maximum 
capacity of the device reporting the 
condition. 


Te At <4-1s> Set toa; 
received and returned. 
contained an invalid N(R 


3. Bits &, and 20 to 23 are set to O. Bit 
12 is set to U if the rejected frame was 
a command, or lif if it was a response. 


(UI) 


control field 
oa 1 to 8 


the 


Unnumbered Information Frame 

The unnumbered information frame is used 
to pass information along the link outside the 
normal information controls. This allows informa- 
tion fields to go back and forth on the link 
py pees 106 flow control. Since these frames. are 
N acknowledgeable, if one gets wiped out, there 
is no way to recover it. 


The UI frame is not defined in X.25. It 
has been taken from ADCCP to allow uncontrolled 
information to flow thru the link without inter- 
fering with a next higher layer. 


Link Error Recovery 
There are several link-level errors that are 


recoverable without tearing down the connection. 
These error situations may occur as a result of 


malfunctions within the DTs or DCH, Oe (at 
transmission errors occur. 
Invalid Frame or FCS Error 
_ If an invalid frame is received or a 
frame is received with an FCS error, that frame 


will be discarded with no action taken. 
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Device Busy Condition 


When a DTE or DCH becomes temporarily 
busy, such as when receive byffers are full, it 
will send a receive not ready (RNR) frame. This 
tells the other side of the link that the device 
cannot handle any more I frames at the moment. 
This condition is usually cleared by the sending 
of a UA, RR, R#J, or SABM command frame. 


Send Sequence Number Error 


If the send sequence number , N(S), of 
an otherwise error-free received I frame 6o0es not 
match the receive state variable, V(R), a send 
sequence error has occured, and the information 
field will be discarded. The receiver will not 
acknowledge this frame, or any other I frames 
until N(S) matches V(2). 


The control field of the erroneous I 
frame(s) will be accepted so that link supervisory 
functions can still be performed, such as checking 
the P/F bit. Because of this updatinag,, the re- 
fo eee I frame may have an updated P bit and 


Reject (REJ) Error Recovery 

ReJ is used to re qiest a retransmission 
of I frames following the detection of a sequence 
error. Only one outstanding reject condition is 
allowed at a time. This condition is cleared when 
the requested I frame has been received. 


A device receiving the REJ command will 
clear the error by sending over the I frame indi- 
cated in H(R) of of the HEJd command frame. 


Time-out Error Recovery 


When a transmission abnormality wipes 
outa single I frame, or the last I frame of a 
roup, there is no way of telling this immediate- 
yy» Since the receiver does not necessarily know 
something was sent until another frame is sent 
resulting in an out-of-sequence error. TO .cope 
with this situation better, some form of time-out 
delay will be pCO ED veces by the sender after it 
sends out a frame. his time-out timer is started 
at the time a frame is sent, and stopped by the 
reception of an acknowledgement for the sent 
frame. If the timer times out before an acknow- 
ledgement is received, any unacknowledged frames 
are retransmitted. The delay is an agreed-upon 
amount that will vary with the ‘type of rf medium 
and signaling speed used. 


dejection Error 


A rejection error condition occurs when 
an error-free received frame has one of the fol- 
lowing problems: 


1. An invalid command or response control 
field. 


2. An invalid frame format. 
3. An Invalid N(R). 


4. An information field that exceeds the 
maximum the device can accept. 


Once a rejection error occurs, no more I 


frames are acccepted (with the exception of 
the P/F bit still usable) until the error is 
resolved. The error condition is reported to the 


other side of tne link by sending a FRMR response 
frame. 


Primary/Secondary versus Balanced Operation 


There are two basic classes of link-level 


Gonnections. The first, known as Link Access 
Procedure (or LAP) is often called an unbalanced 
service where the DCii is considered the primary 


devices and the DTns are considered 
secondary (or slave) devices. Thesecond class of 
service is known as LAPB, Link Access Procedure 
Balanced. In this service both devices are 
treated as equals as far as connection requests 
and other Bias of commands. There is still only 
one DCk and potentially many DTEs, but both ends 
can command the link equally. 


(or master) 


Primary/Secondary (LAP) Operation 
LAP is the older style of link control, 


where most of the intelligence was assumed to be 
in a large mainframe (the DC#) gnd the e users 
were just using smart terminals (the DIEs). Since 
network software can have a lot of overhead it 


made sense at the time to ut most of the overhead 
in the big computer, and just enough smarts to 
make the link work in the terminals. 


Balanced (LAPB) Operation 


LAPB is a slightly modified version of 
LAP. It has been changed to allow the two sides 
of a link to operate in a more balanced manner. 
In the official version of X.25 there is still 
only one DCH to potentially many DT#s, but the two 
can-operate more-as equals than master and slave. 


LAPB is what this document describes for 
use over Amateur Radio packet networks. Even when 
there is a network controller overseeing the net- 
work operation, the balanced link procedure will 
enhance operation. 


Connection Operation 


In amateur radio network operations, it would 
be very helpful if one level 2 protocol would work 
with the various rf systems in use. An example of 
this is the difference in operation between a 


Simple two-station link, and multiple stations 
operating thru a network controller. Obviously, 
when a network controller exists, it should 


while the other station: 


considered the DCz, 
A sinple two- 


connecting to it would be the DTus. 


station connection is another matter. o this 
type of connection the station rae a 
connection should always be considered the DTh, 


while the device that is receiving the connection 
request should operate as the DCE. This simple 
rule should eliminate any ambiguity that might 
otherwise occur under these conditions. 


NOTE There are a couple minor changes from 
the of ficial X.25 standard in the protocol recom- 
mended here. These changes are done only as abso- 
lutely necessary to work over theshared rf media. 
Since X.25 was written to work so that one DCE 
talked with many DTes over a closed network, it 
cannot properly cope with a channel where there 
may be many DCHs linked to many DTius. Some ama- 
teurs have thrown X.25 out because of this prob- 
lem. It seems to take just a couple minor changes 
in the initial link set-up procedure to make X.25 
work properly over ‘amateur radio. Where these 
changes are made, both the original X.25 procedure 
ang ave recommended amateur procedure will be 
noted. 


LAPB Procedures 


The following describes the procedures used 
to set-up use, and disconnect a balanced link 
between a DTH and DCE. These procedures have been 
taken from X.25 and conform very closely to that 
standard, except where it was necessary to change 
due to the radio enviroment. 


Address Field Operation 


All transmitted frames shall have ad- 
dress fields conforming to above-mentioned rules. 
All frames should have both the destination device 
and the source device addresses in the address 
field, with the destination address coming first. 
This will allow many links to share-the same rf 
channel. The destinatilonaddress is always the 
address' of the eet on (a) to receive the frame, 
while the source address contains the address of 
the dveice that sent the frame. The destination 
address can be a group name or club call however, 
if point to multi-point operation is allowed. 
pte will be discussed further under link opera- 

ions. 


LAPB Connection Establishment 


When a device (either a DCE or_DTE) 
wishes to connect to another device, it will send 
a SABM come frame to that device and start a 
time-out timer(Ti). If the other device is there 
and able to connect, it will answer with a UA 


response frame and at the same tim reset boh .of 
ear internal state Vari abica (ICS) and #2R) 9! 
The reception of the UA response frame at the 
other end will cause the device requestin the 


connection to abort the Til timer and se its 


internal state varia'bles to O also. 


If the other device doesn't respond 
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before Tl times out, the device requesting the 
connection will re-send the SABM frame, and start 
{1 running again. This trying to establish- a 
connection will continue unti the requesting 
device has art} unsuccessfully a number of times. 
That number (N1) is variable,” depending on the 
frequency of operation, type of transmission (eg. 
terrestial vs. satellite), and the signaling speed 
in use. N1 will be discussed in another section. 


Information Transfer 


Once a connection has been established 
as outlined above, both devices are able to accept 
I, S, and U frames. 


Sending of I Frames 


Whenever a station has an I frame to 
transmit, it will send the I frame with N(S) of 
the oe VG equal to it's current send state 
variable V(®S). Once the I frame is sent, the send 
state variable is incremented by one. 


; The sfation should not transmit any more 
I frames if it's send state variable ejuals_ the 
last received N(R) from the other side of the link 
ylus seven. If it were to send more I frames, the 
“low control window would be exceeded and errors 
could result. 


it re GSvice. 1S ina busy ‘condition, 1 
may still send I frames as long as_ the other 
device is not also busy. 


If a device is in the frame-rejection 
it will stop sending I frames. 


Receiving I Frames 


_ If a device receives a valid I frame 
with a correct FCS and whose send 


mode, 


(one sequence 
number uals the receiver's receive state varia- 
ble) amd is not in the busy condition, if will 
accept the received I frame, increment it s re- 


ceive state variable, and act in one of the fol- 


lowing manner: 


1. If it has an I frame to send, that I 
frame may be sent with the t ransmitted 
NCR) eve ¥e it's receive state 
variable VCR) (thus acknowledging the 

received frame. Alternately, the device 

y send an RR frame with N(R) equal to 
ve ), and then send the I frame. 


2: If there are no outstanding I frames, 
the receiving, device wil send an RR 
frame with N(R) equal to V(R). 


If the device is_in a busy condition it 
may ignore any received I frames without reporting 
this condition other than repeating the indication 
of the busy condition. 


If a busy condition exists, the station 
receiving the busy condition indication should 
ee the sender of the busy indication periodical- 
-y until the busy condition disappears. 


The reception of I frames that contain 
zero length information fields shall be reported 
to the next level but no information field will be 
transferred. 


When an I frame is received with a cor- 
rect FCs but it's send sequence number does not 
match the current receiver s receive state varia- 
ble, the frame should be discarded and a HEJ frame 
should be sent with a,receive sequence number 
equal to one higher (modulo 8) than the last 
correctly received I frame . Any out-of-sequence 
received I frames should be handled in this man- 
ner. The received state variable and poll bit in 
such a discarded frame should be checked before 
throwing it away, and take any action needed de- 
pending on the condition of them. 


Receiving Acknowledgement 


Whenever anI oor S frame is correctly 
received, even in a busy condition, the NCR) of 
the received frame should be checked to see if it 
includes an acknowldegment of outstanding sent 

f’rames. The Ti timer should be reset if the 
received frame actually acknowledges previously 
unacknowledged frames. If the Tl timer is reset, 
and there are still some frames that have been 
sent that are not acknowledged, Ti should be 


started again. If the Titimer tins out before an 
acknowledgement is received, the device should 
proceed to the retransmission procedure. 


Receiving hegject 


Upon receiving a RiJ frame, the trans- 
mitting station will set its send state variable 
to the same value are the Rtv frames received 
sequence number in the control See The device 
wit then retransmit any I frame(s) outstanding at 
the next available opportunity conforming to the 
following: 


ee If the device is not EeepSmic tie at the 
time, and the channel is open, the ees 
commence to retransmit the I frame(s 
immediately. 


ae If tne device is operating on a full duplex 
channel transmittiong a U or 5S frame ween it 
receives aRkJ frame, it may finish sending 
the U or § frame and then retransmit the 
frame(s). 


oe If the device is operating in a full duplex 
channel transmitting another I frame when it 
receives a KkJ frame, it may abort the I 
frame it was oy Beene and start retransmission 
of the requested I frames immediately. 


4. The device may send just the one I frame 
elec anor or it may send more than one if 
side 


any more ames followed the first one not 
acknowledged, provided the total to be seas 
does not exceed the flow control window (7 


frames). 


If the device recives a RirJ frame with 
the poll bit set, it should respond with either an 
RR or RNeX frame with the final bit set before 
retransmitting the outstanding I frame(s). 


Receiving an RNR Frame 


Whenever a device receives an RNK frame, 
it may transmit or retransmit the I frame whose 
send sequence number equals that of tne received 
sequence number indicated in the RNR control 
field. If timer Ti runs out after the RNR was 
received the waiting acknowledgement procedure 
listed below should be performed. The poll bit 
may be used in conjunction with S frames to test 
for a change in the condition of the busied. out 
station. No I frames other than the one mentioned 
mets ay be sent out before the busy condition is 
cleared. 


Sending a Busy Indication 


Whenever a device enters a busy condi- 
tion, it will indicate this by saat an KNR 
response at the next opportunity. While the de- 


vice is in the busy condition, it may receive and 
process S frames. and if a received 5 frame has 
the P bit set to one, the device should send a RNR 
frame with the F bit set to one at the next possi- 
ble opportunity. To clear the busy condition, the 
device should send either a RR or RJ frame with 
the received sequence number equal to the current 


receive state variable, gopenciS on whether the 
last received I frame was properly received or 
not. 


Waiting Acknowledgement 


The device should maintain an internal 
retransmission count variable which is set (Cine 
whenever another I frame is acknowledged either 
thru the reception of a UA or RNR Pra e, or when a 
received I ors ee has an N(R) higher than the 
last received aR , showing the acknowledgement of 


additional I frames). 
Any time the timer T{! runs out, the 
device will re-enter the timer recove condition, 


the retransmission count variable w be incre, 
ment ed by one, and another internal variable (X) 


will be set to the current send state variable 
value: 


The device will then restart the Ti 
timer, set its receive state variable to the last 
receive sequence number, and retransmit the cor- 
responding I or 8 frame with the P bit set to one. 


The timer recovery condition is cleared 
when the device receives a valid S frame with the 
F bit set to one. 


41n 


If the device receives an 5S frame with 
the F bit set to one and N(R) within the range 
from the current send state variable to X men- 
tioned above inclusive while in the timer recovery 


condition, this condition will be cleared, ,and the 
send gerare variable will be set to the N(R) re- 
ceived. 


If the device. receives an 5 frame with 
the F bit set to zero but otherwise the same 
condition as the last paragraph, the timer re- 
covery condition will JOT be cleared. The re- 
ceived N(R) may be used however to update the send 
state variable. The device may keep the last I 
frame transmitted (even if it was acknowledged) to 
be retransmitted with the P bit set to one if 
timer Tl expires at a later time. 


Ynee the retransmission count variable 
reaches Ne, the device should proceed to the re- 
setting procedures outlined below. 


Link Disconnection 


When in the information-transfer phase, 
either device may initiate a link disconnection b 
sending a DISC frame. It should then start its T 
timer, and wajt for a response. If. the 
response doesn. ti come before T1 times ott, it 
should send the DISC frame again and restart' Tl. 
If this happens N2 times, the device should enter 
the disconnected state. 


When a DISC frame is received, the re- 
ceiver should return a UA’ response frame,, and 
enter the disconnected state. 


Disconnected State 


After having. sent a DISC frame and 
received a JA, or receiving a DISC and having sent 
a UA, the device will enter the disconnected 
state. 


In the disconnected state, the device 
may initiate a link set-up as outlined in connec- 


tion establishment above. It may. also respond to 
a SABM and establish a 


the reception of a connec- 
tion, or it may ignore the SABM and send a DM 
instead. 

Any station receiving a DISC command 


while in the disconnected state should send back a 
DM response frame. 


Any device receiving a command frame 
other than a SABM or UL frame with the P bit set 
to one should respond with a DM frame with the F 
bit set to one. he offending frame should also 
be ignored. 


When the device enters the disconnected 
state after an error condition or if it has re- 
covered from an internal error condition by coming 
U in the disconnected state, it should indicate 
nae by sending a DM resp onse rather than a DISC 


frame. It should start the Ti timer when the DM 
is sent, and if Tl times out befcre getting a SABM 
or bist frame back, it should cond another DM 
frame wand restart Tl. After retransmitting the 


the device will remain in the 
and no other action will be 


DM frame Ne times 
disconnected state, 
taken. 


Resetting Procedure 


The resetting procedure is used to ini- 
tialize both directions of flow after a _non- 
recoverable error has occured. This resetting 

rocedure is only used when in the information 
ransfer phase of an AX.25 link. 


send- 


A device shall request a reset bY 
3M frame 


ing an SAbM frame. Upon receiving an SA 
from a station previously connected to, the re- 
ceiver of an SABM frame should send a UA frame 
back at the earliest opportunity. Both devices 
should then set their send and receive state vari- 
ables to zero. Any busy condition that previously 
existed will also be cleared. 


It is p ossible to initiate a disconnect 

procedure instead of resetting the link. 
One device may ask the other to reset 
frame. After 


the link by pelos a DM response é 
the DM frame is) sent, the sending device will then 
enter the disconnectedstate. 


One device may ask the other to initiate 
a link reset by transmitting a F response 


frame. 


After sending the FRMR frame, The send- 
device will enter the frame re ‘ect state. 

condition is cleared when the aevice that 
sent the FRMR frame receives an SABM or DISC 
command, or a DM response frame. Any other com- 
mand received while the device is in the frame 
reject state will cause another FRMR to be. sent 
out with the same information field as originally 


sent. 


a a 
This 


The device that sent the FRMR fram 
should start the Ti timer when the FRMR is sent 
If above mentioned frames are not received before 
the timer runs out the FRMKR frame should be 
retransmitted, and the Tl timer restarted as des- 
cribed in the waitin acknowledgement section 
above. If the FRMR is sent Ne times without 
suecess, the link should be reset. 


zejection Conditions 


A device should initiate the link-reset 
procedure when a frame is received with the cor- 
rect FCS and address field during the information 
transfer phase witnone or more of the following 
conditions: 


1. The frame is not known as a command or 


response to the device. 


Zs The information field is invalid (as an 


example is longer than 256 octets). 


A device will initiate a reset procedure 


whenever it receives a DM or FRMR response frame 
during the information transfer phase. 

A device may initiate a reset procedure 
also whenever it receives a UA response frame or 


if it receives an unsolicited response frame with 
the F bit set to one. 


Collision Recovery 
Collisions in a Half-Duplex Enviroment 


Collisions of frames of ay type ina 
half-duplex enviroment are essential ly taken care 
of by the retry nature of the Ti timer and re- 
transmission count variable. No other special 
action needs to be taken. 


Collisions in a Full-Duplex Enviroment 


Collisions in a full-duplex enviroment 
are not really frame collisions, ut have more to 
do with the devices being pulled in two different 
directions at the same time. 


Collisions of Unnumbered Commands 


If the sent and received U command 
frames are the same, both devices should send a UA 
response at the earliest opportunity, and both 
devices should enter the indicates state. 


If the sent and received U commands are 
different, both devices should enter the discon- 
nected state, and transmit a DM frame at the 
earliest opportunity. 


Collision of a DM with a SABM or DISC 


When an unsolicited DM response frame is 
collision between it and a SABM or DISC 
may occur. In order to prevent this DM from being 
misinteroreted. all unsolicited DM frames should 


be transmitted with the F bit set to zero. All 
SABM and DISC frames should be sent wich the P Bie 


set to one, so there isn't any confusion when a JM 
frame is received. 


Connectionless Operation 
In Amateur Radio circles, 


sent, a 


there is a type of 
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operation that isn't really feasable using level 2 
connections. This operation is the roundtable, 
where several amateurs may be nae in one con- 
versation. The only way to accomplish this in a 
connected mode would be to have everyone cross- 
connected with each other. This would require a 
seperate frame to be sent to each member of the 
roundtable every time someone says something. 
Obviously, this mode is not practical. The way 
most amateur packet radio enthusiasts have ended 
up eater the roundtable operation is out- 
side he AX.25 connection, but still using the 
AX.25 frame structure. AX.25 does allow a special 


frame for this operation, called the Unnumbered 
Information ( frame. It is recommended that 
when this type of operation is in use, the sdesti- 


nation address have a code word installed in it to 
prevent the- users: of that particular roundtable 
from seeing all frames going thru the shared RF 
medium. An example of this 1s if a group of 
amateurs are ina roundtable discussion about 
packet radio, they could put PACKmT in the desti- 
nation address, so they would only receive frames 
from others in the same discussion. An added 
advantage of the use of AX.25 in this manner is 
that the source of each frame is in the source 
address sub-field, so software could be written to 
automatically display who is making what comments. 


pemrneee this is a kludge to the level 2 
AX.25 protoco THis type of goon teat reall 

belongs at the next layer aver ),. Pace level) 
of operation, but until layer 57 is implemented, 

this appears to be an acceptable substitute. 


Keep in mind that this mode is connection- 

so all transmitted frames shouted’ be of good 
as there will be no requests for retrans- 
missions of bad frames. Collisions will also 
occur, with the potential of losing the frames 
that ‘collided. 


less, 
quality, 


List of System Defined Parameters 


Timers 


It is recommended that there are _ two 
timers used to maintain the integrity of the AX.25 
layer 2 connection. 


The first timer, Ti, ais used to make 
a device doesn't wait forever for a response 
to a frame it sends. This timer cannot be expres- 
sed in absolute time, Since the time require to 
send frames varies greatly with the baud rate used 
at level 1. Ti should be at least twice the time 
it would take to send a maximum length frame to 
the other end of tne link, and get the proper 
onse frame bac« from "the other end of the 
link. This would allow time for the other end of 
the link to do some processing before responding. 


The second timer, T2, is used whenever TI 
running to make sure that a supervisory 
inte- 


sure 


Snot 
frame is sent neriodicallvy to maintain link 


grity, It also will vary dramaticaily depending 
on layer 1 constraints, and is subject for further 
study. 


Maximum Number of Retrys (iN2) 


The maximum number of retrvs is used in con- 
junction with the Tltimer. tt willwary Sieaee 
ing on the layer 1 in use, but will generally be 
sixteen. 


Maximum Number of Octets in an I Field (1) 


The maximam number of octets allowed in 
the I field will be 2bo. There should also be an 
even multiple number of octets. 


Maximum Number of I Frames Outstanding (k) 


The maximum number of outstanding I 
frames at a time is seven. A smaller number nay 
be used at any time, provided it ig agreed upon 
ahead of time. 


Bit, Sent 
Flag | Address | Control || ECS | Flag 
011111198 | 112/168 Bits| 8 Bits | 16 Bits | “01111110 
Fig. 1A. U_and S Frame Construction 
Pires 
Bit Sent 
|__.Flag __J__Address___ | Control|_ PID [|_Info. | FCS [Flag | 


Pigs 1B. Information Frame Construction 


First 
Octet. Sent 
Address Field of Frame 
Destination Address | Source Address 


Fig, 2A. Non-Repeater Address Field Encoding 


First 
Octet Sent 
Address Field of Frame | 
Destination Address | Source Address Repeater Address 


as 8 ee me cee ee ess ee ee se ne en ee OOS eee ee eee eee eee ee ee ee eee eee ee 


em ee ow ce cee ee ee ee ee ee ee ee ee ee ee oe ee ee ee ee ee ee we es 0 ee ee ce ec ee ee ee ee ec ee ee eee ee 


but wi 


field 


indicating 
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Appendix B. 


Octet | ASCII |Bin.DatajHex Data/ 


(O14 
K 1 100 
3 pl 
M j 100 
M 100 
Q (1 
Space ,0Q1 
DoD OT 
W yO 
B p10 
4 {01 
a 
SSLD 01 
W (10 
B j LO 
4 jO1 
J y10 
F j1Q 
l y 10 
SolD 411 
SABM 00 
none 411 
part 14XXx 
part 2;XX 
101 


The above frame is the same as in Appendix A, 
a repeater address 


h the addition o 


WB4JFI, 


repeater. 


this 


osiD=1). 


Appendix A. 


n 
Tak 
@ 


14 { 
Control; SABM 
PI 


SE ee a Re A EE ee ee ne ee 


Repeater Type Operation 


COCOe 


(=) 


Xe) z: 
SOSLS 
OOC~rCocosecocccs 


=P rs OF SP OOCCO 
Orx<rs CA -OOC 


The H bit 
is from the output of 


O>tH Oro} 


O27 SS OHO 
ROOCr 
ROSS— 


g 


rr ne em ee ee ee ee ee ee ee ee 


The frame shown is an SABM frame 
hru a level 2 repeater, 
MMO (SSID=O), with no level 4 protoc 
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j=) 


~ 


Sa 


GS 
eC 
e 
COCCOCCCO 


>» 


1110000 

1 XXXXXXXX 
2 | XXXXXXXX 
jO11111107 


from WB4JFI 


Non-Repeater Frame Example 
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not going 


(sSID=0 to 


Appendix C. 


Advantages of the WB4JFI Addressing Scheme 


Some of the advantages to using this 
addressing system are: 


Every packet station will have a unique 
fixed address that doesn't change every 
time anew network is logged into. 


search ing to a new area won't cause 
major (or minor) problems. 


Allows for more than 62 or 4lusers at a 
time. 


No local packet guru is needed to assign 
addresses with attendant concerns of 
backup and transfer during failure. 


Direct or network operation requires no 
change of address. 


All the pro'blems with dynamic 
allocation/de-allocation are eliminated. 


Reduces local co-network interference due 
to users in overlapping local network rf 
domains with the same address fields. 


With every frame having both the 
destination and source addresses in them, 
it will be a lot easier to set-up and run 
multiple connections on the same data 
channel without having problems arise as 
to who is sending what frames to whom. 


In round-table operation, every frame 
sent will have the source address 
imbedded In iJ, Allowing automatic 
printing of the source of -the frame. 


pl? 


Appendix D. Layer2 AX.25 State Table 


; Both Devices Busy 


| state | _with|I with-|RR with|RR with-(REJ with|REJ with-(RNR with|RNR with-| SABM, DISC! { UA | DM | FRAR 
iduasasacasacvocreese PE OE Nee ee a De oO et ee ee 
joi Disconnected 1 DM | DM i DM DM iUA,S5 DM | SABM,S2 | 
|S2 Link Setup __ | | | | | | | | | UA | DM,sti $5 {| St | 
83 Frame Reject 1 FRR 0} PRMR PRMR | 000} FRMR A UAVS JUST | | |SABH,S2 | SABH,S2) 
{84 Disconnect Rast | ______ eee eens eee Pome NOeeE [sae ote renner enero Jo) ae oe |, opel (ae 
i985 Information xfr | RR | r }| rt |] zr | 3 {4  r 4 89 | S89 | UA |uA,St {SABM,S2/SABM,S2 | SABM,S2! 
jS6-REJ Frame Sent | RR,SS| 195] oT 4 tf ob ft 4 Sts ft 815 1UA,S5 [UA,SI_| SABH,S2 | SABN,82 | SABH,S2 
iS] Waiting Acknow, j RR} Tf 285 4 204 295 1 oT 4 $9 fot 1ua,So HUAI | Sasit,s2} Saba oe | SABI, Se] 
ee a ee eee eae 
Isy Remote Device | RR {| RR | 1,95] 1,95 { 1,85 | 1,85 | | (UA,S5 |UA,S1 | SABM,S2| SABM,S2 | SABM,S2 
fepeeness eee art mn EE a TOR SEL IVR aeRO oe eR REA NSE ME Ere SNe HEY yt ce es meen Mae Ree. eee 
|S10 Both Devices | RNR | RNR | I,s8 | 1,88 | 1,88 | I,s3 | | UA, SG | UA,S1 | SABM,S2) SABM,S2 | SABH,S2 | 
LREIOE ee ene re one Seen eL Ee een, a eimer meee Re em ree ret Cee ee (ery tepercert en eae, Soreneere ae reeeen ene Alen Aaeer eee | 
1Si1 Waiting Acknow.| RNR | RNR | I,88 , I | I,s3 | I | Slo | St3  {UA,S8 {UA,St | SABM,S2]}SABM,S2] SABM,S2) 
|and Device "Busy i) teehee De eteaced| Gera Rehes acne eee sain arereed ecaeeee eae. 
{S12 Waiting Acknow.} kR | RR } 1,85 | I,87 | 1,85 | 1,87 | : \UA,S5 {UA,S1 | SABN,S2 | SABM,S2 |SABN,S2| 
and Remote Busy 1! |} | gen. ee ees cess peed ee er eae aide Eas ae 
's13 Waiting Acknow.| RNR | RNR | 1,98 | 1,811 | I,s8 | I,stt | , \UA,S8 |UA,St | SABH,S2 | SABM,S2 | SABM, S2| 
; Both Devices Busy | \ | SS ae oon Cee en Renee 
|Si4REJ Sent and, RNR | RNR | I | Ir 4 EF | © | St6 | St6 | UA,s81 UA,St| SABM,S2] SABH,S2 | SASH,S2| 
| and Device Busy | { Ei 7 | Meat ig nara teh a coal ity tg tt SE eee hg eat celta a fae ee Pee : 
S15 RuJ Sent and |RR,S9 } RR,S9 | 1,86} 1,86 | 1,86 | 1,96 | jUA,S5 {UA,S1 \SABM,S2\SABM,S2 , SABM,S2 
j Kemote Busy | | | | | | | | | | 

j316 Rid “Sent and =, RNR | KNR | 1,814) 1,814 4 1,014 | I,S14 | 1UA,S5 | UA, ST {SABM,S2)SAbM,S2 4 SABI, S? 
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LEVEL 3 POSITION PAPER 


Terry Fox, WE4JFI 
Vice-President, AMRAD 
1819 Anderson Road 
Falls Church, VA 22043 


Introduction 


Now that the amateur packet radio community 
seems to have agreed on a protocol at layer 2, the 
link lgvel of the Open System Interface Reference 
Model (OSI-RM), it appears that it is time to 
begin work on the'layer 3, or network layer. 
Layer 3 is actually made up of two sub-layers, a 
local or metro pe network sub-layer, and an 
internetwork sublayer. 


The local area network is responsible for the 
proper transfer of packets among a Sion of local 
users. The term local can be misleading, as a 
local network could actually be a network operat- 
ing on hf, where the participants are Seraaiy 
spread out over a large geographical area. A 
local network is generally concerned a group of 
devices interconnected directly together at the 
layer immediately above the link layer. These 
devices may be corresponding directly, or they ina; 
C operating thru artintermedia such as a loca 

or metropolitan) network cont rolier. 

The internetwork sub-layer is half a step 
above the local network, and is used to intercon- 
nect individual local networks. This allows a 
user on one local network to communicate with 
another user on a different local network. De- 
pending on how the irt ernet sublayer cperates 
another layer above it (layer 4, transport layer) 
may be required to assist in the re-assembly of 
data sent over the internet layer. 


Types of Network Qperation 


There are two basic types of networks, both 
at the local and Gaerne: sublayers. One is 
the connection type, and the other is the datagram 


ty pe. 
Connection Type Networks 


The .connection eye of network requires 
a connection be established and maintained between 
the two devices wishing to communicate before any 
data can be transferred. The connection looks 
very much Jike the HDLC type layer 2 links that 
are established before I frames may be passed 
along the link. 


The connection network is like a small 
town telephone company. Whenever a local call is 
made, as long as it is between the same two peo- 
ple, the gonnection will be made the same way 
every time Gantt for a different reason though, 
because that’s the only way a connection can be 
made between the two people, not necessarily the 
best way). in a connection network, once the 
connection is made, all frames JUST follow the 
same path. If anything should happen to that 
path, the connection must be torn down and re- 
established over again. 


The main advantages of the connection 
type of network are.: 


i Once the connection is established, very 
little overhead is required to maintain 
proper operation. 


2 Generally, a connection oriented network 
does not allow data packets to be 
received out of their proper sequence, 
thereby greatly simplifying the 
transport layer required. 


Some of the disadvantages of the connec- 
tion type of network are: 


if Once a connection is’ established, all 
packets must follow the path generated 
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while the connection was being made. This could 
be a problem if either the network or one of the 
devices involved are marginal in nature. 


ys Out of sequence packets are not, usually 
allowed, meaning a valid ipacket may have to pe 
retransmitted because an earlier packet got lost. 


Datagram Type Net-works 


A datagram type network operates in a 
different manner than a connection tae network. 
Eech packet in a datagram network contains a head- 
er’ tnat should have all the information necessary 
to et it from its gource to its destination 
tctally independently of all packet:; sent; before 
or after it. A datagram network is like sending a 
bunch of letters to tie same person on different 
days from the same post office-; Just because the 
same post office was used, and the addressee is 
the same, doesn't mean all letters follow tne same 
path from you to the destination. 


The basic advantages and disadvantages 
Of a datagram networx are Just the opposite as 
those of the connect ion network. White every 
packet can be routed a different way (potentially 
going around trouble spots in the networx), the 
added size of each packet (due to a larger header) 
nd the added cornplexity of the transport layer 
to re-align out Of sequence packets) add u to 
more overall complexity in the software or ee 
ware used to implement a datagram network. 


History 


When AMRAD first started looking into the 
layers higner than layer 2, we were soldon_ the 
datagram type of network. It seemed to us that 
the amateur radio enviroment that a network must 
operate in can become ve ry unreliable (not only 
because the rf medium may vary dramaticaily but 
also because of the voluntary nature of tne 
amateurs participating). DJatagrams can f jnd their 
way from on end of a network to tae otner 70 
matter how convoluted the network ma,y become due 
to eyuipnent or operator failure, as lea as there 
is a least one good path to the See acon. 


Our initial decision to use a datagram 
network was ulckly temperec however, when we 
found out how dares a program would be récuired to 
handle datagrams properly. We couldn 't find 
anyone who was operation a network level datagram 
service without having implemented ina higher- 
level language on a large mariframe computer (or 
at the very least a mini). Ubviously, weweren't 

ee to write a program of this size in the not 
oo distant future. 


When AMRAD got together with the New Jerse 
packet contigent to discuss the level 2 AX.2! 
protocol, we met at Telenet witn Eric Scace, KiwWA. 
Eric has worked with X.25 for quite a while (he 
was involved in the writinzof’ tne X.25 recommen- 
dation) and he was ale £0 bring to our meetings 
invalua ble insight into the inner workings Of 
x.25. I found out there is a hugh di f ference 
between reading a protocol specification, and 
talking to someone about that protocol: actual 
implementation. Eric was able t 0 convince us th at 
a connection oriented network such as X.25 could 
be implemented properly in an amateur_ radio 
environment. He also halped us decide how to 
implement the X.25 level 3 protocol properly, and 
how to add information necessary to make the prot- 
ocol operate in an Amateur Kadio enviromert while 
still maintaining the integrety of tne X.<9 proto- 
col specification. Fortunately, Hrie was” able 
meet witn the packet crowd at the AMSAT sponsored 
get-together last October. I think that a lot of 
questions were answered at that meeting, and al- 


though the rest of the crowd isn't convinced that 
X .25 is the proper way to go at laver 3, we at 
AMRAD have decided _to go wi mX.25 for our local 
network. Gordon Beattie Jr., N2DsY rom The 
Radio Amateur Telecommunications Society the New 
Jersey group mentioned above) is in the process of 
writing up the layer 3 AX.25 protocol specifica- 
tion now, and itwill be available soon. 


Basically, AX.25 level 3 follow the CCITT 
X.25 level 3 protoces having to do with virtual 
circuits. All references to datagram and perma- 
nent virtual circuits are to be ignored. 


We have added two amateur radio network faci- 


lities. These facilities allow for either expli- 
cit route selection or implicit route selection. 
Explicit route selection is where the requesting 
station describes exactly the route the connection 
should take. Implicit route selection is where 
the requesting station describes where the station 
ee ane the actual path is determined by the 
network. 


Unfortunatly, the level 3 protocol is just 
too complex to present in a pele of this type, sO 
if you are interested in AX.25 layer 3Jdetails, I 
Suess’ you. get in touch with AMRAD or Gordon 
Beattie, and we will keep you advised as the 
protocol develops. 
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A NEW PACKET-RADIO CONTROLLER BOARD 


Terry Fox, WB4JPFI 
Vice-President, AMRAD 
1319 Anderson Road 
Falls Church, VA 22043 


Abstract 


This paper des ribes the AMRAD packet assem- 
bler/disassembler APAD) to be released soon. It 
is Zilog Z80A based, uses a Zilog 8530 serial 
communications controller and is packaged on an S- 
100 pc board. 


Introduction 


One of the main problems with packet radio is 
that until recently there hasn t been a lot of 
hardware to support the various protocols bein 
used. Hxcept for a few pockets of activity, mos 
of North Americ has adopted the idea of using 
separate board 4usually a single-board computer 
to handle the actual generation and reception of 
frames. The first production board available to 
the amateur to do this was the Vancouver Amateur 
Digital Communication Group's Cae Nod 
Controller fc : This board was (and still is 
available primarily as a bare board which had to 
be built up by the packet enthusiast. The board 
uses an Intel 8085 processor, 4k each of HPROM and 
static RAM. a serial or parallel device to 
communicate’ to your terminal/cornputer and an 
Intel 8273 HDLC controller. The VADCG @NC moved 
the packet-radio software from the host  corrp uter 
to a separate board, and at the same time allowed 
any people to use a simple terminal with packet 
radio. 


The next board that came out was designed by 
and is available from the Tuscon Amateur Packet 
Radio Corporation (TAPH). Its basic desi hilo- 
BODY is the same as the VADCG TNC in that it also 
handles all of the frame-level aqeneration and 
reception of packets, requiring only a terminal_or 


serial/parallel interface to a computer. Lts 
actual -hardware design is quite a bit different 
from the VADCG TNC, however. In addition to a 


different CPU (a Motorola 6809), it boasts quite a 
bit more memory (six byte-wide RAM/EPROM sockets 
normally fitted with 24k of HPROM and 6k _ static 
RAM), a different HDLC controller chip (Western 
Digital 1933), timedinterru ts, a non-volatile 
memory, and a corrplete ia) 262 cormp atible modem 
(using the Exar modem chips). The TAPH group had 
time to study the VADCG TNC and made a_ lo of 
improvements when they designed their board. An- 
other advantage to the TAPR TNC is that it is 
urchased as an assembled board, reducing greatly 
he chances of failure for the user. One of the 
many roblems with the TAPR TNC actually has no- 
thing to do with the board itself. TAPR has had a 
lot of problems getting the boards designed and 
into production. As of when this paper is being 
written, TAPR is getting the boards out to the 
last of their customers. This is one of the 
disadvantages of being out at the infamous leading 
edge. This also shows that the TAPR group doesn 
want to send out TNCs that aren't as good as they 

can be, and the boards are definitly worth the 
wait. 


Be Amateur Radio Research and Development 
(AMRAD group has been watching the progress of 
these boards with interest for quite a while now, 
and we figured it was time we got into the act. 
Most of us in AMRAD that are into the development 
stages of packet radio use S-1VUU based __ systems, 
usually with 480 processors. So the TAPR TNC is 
rather difficult for us to write software for. 
Also, while having the modem on the TNC as nice 
for two-meter operation. However. when testing 
new ideas out for hf operation or btherwise when a 
different modem is needed, all the on-board modem 
does is take up board space. 


We had some different problems with ke VADCG 
TNC. The primary one is that the memory (both RAM 
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and EPROM) are too small. I have modified the 
EPROM space to allow, the use of either 2716's (u 

to 8k EPROM) or 2732's Gc. to lok HPROM), but no 

many people want to take an X-ACTO (tm) knife to 
their board. Bill Danielson, NoFQR has modified 
the VADCG TNC to run 2k static RAM chips and also 
be able to download software from another computer 
to the INC during software debuggting;,. but here 
again, the board must be butchered. 


We have come eas with an S-100 board that 
contains an Intel 6&274 protocol chip and some 
suas logic so_ that we can write and debug 
software for the VADCG TNC in our S-100 systems 
before blowing anv EPROMs for the VADCG TNC. This 
system works very nicely when coming up with 
changes in existing software, or working on_some 
radical new idea whthout having to reburn wPROMs 
for every failure Ga. I haven't written error- 


free code in a long time). 


An additional problem with the VADCG TNC is 
that the baud rate on the aed channel is 
hardware selected and it goes down only to 600 
bauds. Another modification was made to allow the 
baud rate to be software selectable and to allow 
tne slower speeds needed for hf operation. 


The AMRAD PAD 


The further along we went with packet radio, 
the more kludges we needed to make on the VADCu 
TNC to allow us to do the experimentation we 
wanted. Since the TAPK TNC was in the initial 
design stages and using a processor we weren't 
accostomed to, it became app arent to us that it 
would be easier to design and build a whole new 
TNC board. 


After making the decision to design our own 
board, we next had to decide what to put on the 
board. and what physical size it should be. I'm 
Sure ‘that it will come aS a surprise to almost no 
one that the board will fit into an S-100 frame, 
and steal its power off the S-100 bus. This does 
not preclude tie possibility of using the board 
stand alone with a single S-100 edge connector to 
8 4PPey power if the user isn't using an s-100 
system. 


Basic PAD Layout 


aa 1 shows the basic layout of the AMRAD 
E stands for Packet Assembler/Disassem- 
bler). The PAD was designed to be very flexible. 
In addition to allowing the user to co nect to it 
in either serial or parallel mode 4the other 
boards do this also) itt aiiows for fully adjusta- 
ble baud rate on both serial ports, and if neces- 
sary, both serial ports can be programmed to be 
HDLC channels. It also has room for controlling 
the speed of a multi-speed oe moden. 
The large amount of memory allows for downloading 
and debugging of programs in the PAD ratther than 
needing another simulator board in a larger micro- 
computer. The large RAM space also allows a lot 
more space for buffers and other storage,, meaning 
that the PAD should be able ‘e run more than one 
connection per HDLC channel (something that could 
come in handy in the near future). The #PROM area 
can programmed to accept 2716, 2732, or 2764 de- 
vices allowing plenty of room for expansion. A 
detailed description of the PAD board follows. 


PAD Power Supply Circuitry 


The power pecs ody to operate the PAD board 
is supplied thru the Si QO bus connector on the 
bottom of the board. The PAD uses three voltages, 
+8V at about an amp, +18V at about 50 milliamps, 
and -18V at approximately 100 milliamps. These 


voltages are regulated on the board to SUEDE the 
+5 volts and + l'é volts that the rest of the board 
requires. The five-volt bus has two 7805, T0-¢20 
type voltage ragsuietors one on each side of the 
board. The + twelve-volt regulators use the smal- 
ler, TO0-92 -style packages. These voltages are 
used primarily for the -~252 driver chips and the 
real-time clock. 


In addition to the power supply mentioned 
above, there is also a battery supply on board to 
run the real-time clock, the standby RAM chip, and 
some of these devices eu poet logics .- The. P also 
has a_ sense circuit on board to tell the clock 
chip when-to go into the standby mode because the 
power is being shut down. This is accomplished by 
using a micro-power op amp that monitors both the 
battery voltage and the +b-volt bus, and sends an 
active low signal out when the main power is below 
the battery. 


Z80 CPU and_Support Circuitry 


The PAD board is designed around the Ziloa 
Z80 processor. The master oscillator is an Intel 
8030 support Ic, the 8224, running at 18.432 Miz. 
This frequency was chosen because it is a multiple 
of the common baud-rate frequency of 1.8432 Muz, 
and also because it is high enough to be used in 
the refresh logic for the dynamic memory. The 
master oscillator is divided oy five to produce a 
3.60864-MHz clock for the Z8Q0 CPU, along with the 
rest of the board. ‘This frequency is a multiple 
of the 1.8432-MHz clock desired, so if can be used 
as the clock input to the serial-interface chip. 


The Z30 reset logic consists of one half of a 
dual D flip-flo to make sure that all devices 
using ener ae a properly timed signal. The 
Z3u's NMI pin is optionally connected to a 
pushbutton to allow away of interrupting CPU 
operations for debugging. 


The Z80'g RD and WR signals are buffered, 
since Eney are fed to many_of the other devices on 
board. ORQ and Ml* are ORed together to produce 
eS that is used by the 8530 interrupt support 

ogic. 


EPROM Memory and Support Logic 


There are four 28-pin sockets provided for 
EPROMs on the PAD board. They have been. placed so 
that Textool Zero-Insertion-Force(4ZIF sockets 
can be used if the EPROMs are going to be changed 
frequently (they are recommended /. A jumper area 
is provided to _ allow the EPROM spacee to be 

roe aes for 2716, 2752, or 2/64 type EPROMs. 

f 2716's are used, 6110 type RAM chips also can 
be plugged into the EPROM sockets, allowing a to 
62k of RAM and one loader EPROM to be used. his 
mode of operation is advantageous when testin 
software written on a larger system and downloade 
to the PAD. It also cones in handy when debugging 
the dynamic RAM .since the static RAM in the EPROM 
socket will allow monitors or memory testers to 
run properly. 


A 74LS5138 decoder is used to provide the chi 
enable to the EPROMs. There is also a_ signa 
generated called PROM*, which is used to automati- 
cally deselect the EPROM memory space from the 
dynamic memory. 


Dynamic Memory and Support 


The dynamic memory consists of eight 4164 
type chips for a potential of 04k of memory. When 
this board was in its initial design stage, 4116 
type devices were used since they provided'a lot 
of memory for a very little amount of money and 
board space. As the PAD design progressed; the 
prices of the 64k chips dropped down to where it 
became cost effective to put them on instead. The 
refresh support logic is the same for both types 
of devices, and the elas supply considerations 
are simpler for the 64k chips. The 64k devices 
also generate less noise on the power bus. 


The sixteen address lines from the CPU are 
GW ep aS tee onto the eight address lines of the 
4104°°s with 74LS197 multiplexers driven by a 
select fiming signal. This select signal ,RAS*, 
and CAS etenete are generated by three b- type 
pag bat flops hat are driven by the_ two clocks 
mentioned earlier, M1*, MREQ*, and .RFSH’ signals 
from, the Z8U CPU, and some additional logic. The 
PROM* signal mentioned earlier is added into the 
refresh logic to deselect the dynamic memory when 
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an PROM might be addressed instead of RAM. 


The refresh logic is of standard design taken 
right out of the Zilog dynamic memory interface 
ap lication note. The only differences are the 
a feton of the two added address lines into the 
address multiplexers, and the use cf a times five 
clock instead of a times two clock. This higher 
clock rate is eee! better because it causes 
the refresh signals to be within tolerences where 
a times two signal would cause some timing signals 
to be slightly out of specification. 


Input/Output Decode Logic 


Most of the port decode logic consists of one 
IC, a 74L8138 decoder. It sends chip-select sig- 
nals to the various I[/0 devices, except for the 
real time clock and standby RAM ae Because 
the real-time clock and stand-by KAM chips use 
many more ports than the other devices they have 
separate chip-enable logic. The following 1s 4 
brief chart of the port assignments on the PAD: 


HEX ADDRESS DEVICE 
cm 03 C5 I) CC 


U4-O07 Terminal PI0 
O8-OB Auxilliary PIO ~ 
OC-OF Clock Interrupt Latch 


10-13 Standby RAM Latch 
Real Time Clock Chip 
Standby RAM Chip 


8530 and Support Logic 


The two serial channels are generated by a 
relatively new device +to the amateur packet 
enthusiast, the Zilog 8530 Serial Communications 
Controller, Or: .6CC. When the PAD was in its 
initial design, it used the Intel 8273 protocol 
chip. This was the chip that most of us were 
familiar with, and software already existed to 
drive the 3273 properly. When we discovered the 
8530, we realized that it could greatly simplify 
the PAD. Not only does it have two completely 
programmable channels, it also has two separatly 

rogrammable baud-rate generators, and two DPuls. 
his one chip can support both the HDLC packet 
channel and the serial channel to the terminal or 
computer. In addition, if the terminal or compu- 
ter is interfaced to the PAD board thru the paral- 
lel port, both serial channels can be used as HDLC 
acket channels. This might be useful when the 
AD board is used with a larger computer as a 
aateway between two net-works. or if one channel is 
assigned permanently to one type of operation (say 
hr), nd the other is used for a radically opera- 
tion ay vhf or phone line interface to Telenet 
Cr ARPA). 


Even though the SCC is designed by the same 
corm any as the Z30 and it is supposed to be eee 
tib le, there are some timing problems between the 
SCC and the CPU. The main problem has to do with 
interrupvt-acknowldegement timing. The SCG is 
designed to work on the Zilog 2Z-BUS, and _ its 
daisy-chain interrupt structure is slightly diffe- 
rent than the Z80 peripherals used on the rest of 
the PAD board. This timing problem is cured by 
adding a couple chips that are used to extend the 
time of an interrupt-acknowldegenent cycle, and 
also allow the SCC tobe properly reset" by -hard- 
ware. The timing of this delay is accomplished by 
waiting the Z30 CPU with a delayed signal from a 
74LS164 shift register. As with the dynamic re- 
fresh s0eie mentioned above, this modification is 
right out of an application note from Zilog. 


Since both of the serial channels can be used 
as HDLC channels, it was decided to put timers on 
the RIS signal of both channels. ese are 555 
type timer designed to time out in about 30 
seconds and stay off until reset by RTS changing 
back to an inactive state. The timer output of 
each of these time-out circuits are fed back into 
the CPU thru two bits on the auxilliary Plu, 
allowing the PIO to be programmed to generate an 
interrupt anytime the timer changes state. Not 
only does this give a fairly positive indication 
that the transmit command was successfully accom- 
plished, but it also gives the CPU an indtcation 
if a time out has pocee aan? allows for a fairl 
erect 1 recovery (as opposed to hitting the rese 

utton) after a time-out situation. These timers 
can be jumpered around in both channels if they 
aren't necessary. 


The auxilliary PIO output side generates two 


signals that can be jumpered into the transmit 
data signal from the SCC. These signals are 
useful For adding a cw i-d by changing the con- 
nected modem between mark and s face independantly 
Of =the: -SCC This means a cw i-d can be generated 
without having to change the SCC gs operating mode 
and kludging the software as is done on the VADCG 
TNC. Hopefully this will simplify both the SCC 
Support software and the cw i-d routine. 


The. vest. -0f “che. SCC support ae consists of 
TTL/RS-232-C interface chips to allow the SCC to 
communicate with modems or other RS-232-C type 
devices. 


The connectors used for the serial channels 
are the standard 26-pin insulation displacement 
connector IDC wired so that when crimped to a 
cable with a DB-25 on the other end, the RS-232-C 
Signals will come out on the correct pins. 


PIO Circuitry 


The PAD has two 280 PIO chips on it. One is 
used for an optional terminal or computer inter- 
face if the user wishes to communicate with the 
IG ean 


daisy-chain if this chip is not installed. bet at 
is being used, its output signals are fed thru a 
74i8244 octal buffer to provide enough drive to 
run the signals through a relativelylong cable. 
The connector used for the parallel interfaces are 
the standard 2o-pin IDC connectors and are wired 
the same as most parallel ports using this connec- 
tor. 


The auxilliary PIO is used to generate and 
receive several signals used by the PAD board. 
The parts of the aux P10 not needed for on-board 
functions are fed to a standard 26-pin connector, 
so they are available to the user for whatever he 
wants. In addition to the lines mentioned above 
that are used by the SCC interface, three lines 
from the out ut are sent to the channel A dADLC 
interface so !hey optionally can be used to con- 
trol the speed of a multi-speed modem, such as 
might be used on hf. 


Real-Time Clock and_ Support 


The real-time-clock See used is the National 
Semiconductor MMo3107. In addition to keeping the 
time of day, it can generate timed interrupts to 
the CPU. and it also has an alarm function, 
allowing' it to wake up the rest of a system at a 
preset time. Power tor the real-time-clock chip 
1s obtained from the plus twelve-volt bus thru a 
zener diode regulated power me ly, some switching 
diodes and a battery supply. re allows for more 
time to cleanly shut down the system and prevent 
the clock chip from losing its memory. 


The clock chin is not part of the Zilog 280 
family, and it does not generate any interrupt 
vector when it interrupts the CPU, so an octal 
tri-state latch was added to the board to rovide 
an interrupt vector when the clock generates an 
interrupt. This vector is loaded by the CPU, so 
it can be pro gammed to be just about anything 
that the CPU will recognize. 


The clock chin's power-down interrupt* is an 
poses output thet is fed to the aux parallel 
2d-pin connector, allowing this signal to be used 
by external logic to power up a system. 


Standby RAM Logic 


The standby RAM is a_.6514 low-power eee 
static RAM (organized as a 1024-by-4-bit device 
that is addressed as a series of input/output 
ports. The upper three address bits to the 
chip _come from a four-bit latch. This allows the 
use of all 1024 nibbles in the RAM chip. The RAM 


is automatically deselected on power down pre- 
venting it from being glitched by power ransi- 


tions. The RAM can be used to store -the amateur 
call, speed on both serial channels, whether the 
terminal/computer is using a serial or arallel 
channel, and many other PAD attributes thst should 


be saved during power down. Using a battery- 
backed-up RAM ae tesd of a NOVRAM al lows the RAM 
to be updated much easier and more often, in 
addition a simplifying the hardware design. 


Software Considerations for,,the ,PAD 


The first software running on the ?AD is a 
Z30 monitor modified to run on the PAD. The 
software required to run the PAD on AxX.25 level 2 
is being developed right now, and should be avail- 
able just about the same time as the _ hardware. 
This software is written to take advanta e of the 
PAD s features including the potential ?or down- 


loadin the protocol program and also allowing 
multiple connections. This software is taking a 
little 


longer to eo rimarily because it is 
being written for a TDLZ80 assembler rather than 
using a higher-level language. 


The Zilog 8530 SCC has sixteen write and nine 
read registers internally for each of the two 
serial channels. They are addressed oy first 
writin a pointer to the control register of the 
eiennor of interest, then the requested register 
can be accessed. These registers allow each 
serial channels attributes to be programmed, f'rom 
whether the channel is to be synchronous or 
asynchronous’ to the type of flag character used. 
The registers have to be programmed in a certain 
order to obtain proper operation, especially when 
using the SCC in HDLC mode. For more information 
on the SCC and its internals. see the AMRAD 
Newsletter for January of 1983. 


The National MM58167A clock chin has 24 in- 
ternal registers available to the programmer. 
Eight of these registers are the counters’ that 
contain the time, another eight contain the 
"alarm" time, and the rest are used to control or 
read the various internal functions of the chip, 
including such things as the interrups handling, 
individual counter resets, and the standby inter- 
rupt (power down alarm) control. 


; The, parallel input/output chips are standard 
ZOOA PIO s. They have four modes of operation for 
each of the two parallel channels per chip (except 
forport B not being able to run mode 2. The four 
mcdes are: 


Mode 0. Output mode. 
Mode 1. Input mode. 

Mode 2. Bidirectional mode. 
Mode 3. Control mode. 


The terminal PIO is capable of Prune sleigh 
ary of the four modes with no rodlems. The 
auxilliary PIO is used to Coneee! and monitor 
several of the internal PAD operations, along with 
having a few bits left over for such things as 
mcdem-s peed control. The aux PIO has the outputs 
of the transmit timers going to it for example, so 
if' port A of the aux. BIO was put in mode 3, it 
could monitor the timers and generate an interru t 
whenever the timers output changes state. The 
PI0Os do generate Z30 style interrupt vectors, so 
this could be accomplished very easily, allowing 
ar. elegant recovery from a time-out condition. 


PAD Availability 


The PAD will be available only as a bare 
board for a while, due to cayoital limitations. I 
will be able to offer some of the harder-to-find 
corm onents on a sporadic basis for a while. dHope- 
eae we will be able to support the board bet ter 
in the near future. Anyone interested in this 
pee should write to me at the address listed 
above. 
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Fig. 1 - Block diagram of PAD. 
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DESIGN DECISIONS FOR THE TAPR TNC LINK LEVEL 


David Henderson, KD4NL 
2621 W. 164th St. 
Torrance, CA 90504 


Abstract 


The decisions that were made up front 
on the software side of the TAPR project 
have had a very strong impact on the 
implementation and success of that project. 
Following is a review of some the design 
decisions that were made long before coding 
started, and a chronicle their impact upon 
implementation and performance. 


Introduction 

Before the software description 
starts, lets run through a quick overview 
of the hardware. The microprocessor is a 


Motorola 6809; the memory complement is 24 
kilobytes of EPROM, 6 kilobytes of RAM, and 
32 bytes of electrically erasable ROM. The 
peripheral chips consist of a Mostek 6551 
asynchronous interface adapter, anda 
Western Digital 1933 HDLC interface chip. 
There is also an Mostek 6522 for clock 
Support and onboard parallel =1I/0. The 
potential of using a parallel port for 
term inal 1/0 is provided with a Motorola 


6820 parallel port chip. The computer 
system used as a software factory for the 
onboard software was an HP-64000 


microcomputer development system present at 
the University of Arizona. This system 
made possible the installation of the TNC 
software on the TNC hardware. 


The entire software development cycle 


was focused on are ana The AT&T BX.25 
document was taken as a reference for LAPB 
(reference l), and the AMSAT document 


(reference 2) was taken as a reference for 
the header construction. The transition 
tables in the BxX.25 document were followed 
very closely for the connect/disconnect 
sequences, but the I-frame manipulation was 
implemented in other ways, as described in 
more detail later on. 


Architecture 


The number one design choice was to 
write as much of the TAPR code in Pascal as 
possible. Pascal was chosen because it is 
a widely available high level language, and 
the existence of sophisticated compile time 
options for debugging implied the Pascal 
checkout could be started either on a big 
timesharing or or a microcomputer 
Pascal system. 


The choice which influenced the rest 
of the implementation the most was to have 


the high level Pascal code sit ina tight 
loop checking flags that are continually 
being set and reset by interrupt code 
written in assembly language. This design 
decision paved the way for implementation 
and checkout of the Pascal source without 
having to have the hardware actually 
running, and greatly simplified the design 
of the Pascal code since it did not have to 
deal with interrupts. There was also a 
complicating factor in that flags are 
continually being set and reset to schedule 
future actions in the Pascal code; that is, 
the main loop of code was a sequence of IF 
and CASE statements that check these 
important flags. The action taken by the 
code is not immediately apparent upon 
reading the code; you have’ to know the 
meaning of the flags being manipulated, . 


The next design hurdle was’- the 
buffering; how many buffers should there be 
and what mechanisms were to be used to move 
data from one buffer to another? The main 
task, being a INC, needed only two buffers, 
one for the incoming data flow and one for 
the outgoing data flow, and it was thought 
at one time that only two buffers would be 
needed. Once digipeating and | -control 
functions were considered, it was clear 
that four buffers were needed ~ there had 
to be a way to shuttle HDLC input data to 
the HDLC output queue and a way of talking 
terminal input data for commands, acting 
upon the commands, then printing a response 
to the terminal. The software was then 
broken up into four distinct sections; each 
section moves data from one buffer to 
another, with the possible side effects 
such aS parameter changes. One section 
moved data from the HDLC input ring to the 
terminal output ring, another moves data 
from the terminal input ring to the HDLC 
output ring, a third took data from the 
terminal input ring and produced status 
messages in the terminal output ring, and 
the digipeating process move HDLC frames 
from the HDLC input ring to the HDLC output 
FANG 


The next choice was to have the 
software 'know' as little as possible about 
the half duplex nature of the radio link. 
Previous implementations such as Vancouver 
Area Digital Communications Group protocol 
(VADCG for short) had used the poll/final 
bit in messages to turn the link around and 
have the receiving side turn into’ the 
transmitting Side. I did not. fully 
comprehend the use of the poll/final bit in 
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this manner, and this use of the poll/final 
bit certainly conflicted with the LAPB 
usage. The design decision chosen for this 
"when do I send" problem can be simply 
stated: Only acknowledge receipt of 
messages or send messages when the modem 
Signal data carrier detect is not present, 


or the data carrier detect signal has 
dropped at least once since receipt of a 
message. This rule means that message 


acknowledgements will be generated once for 
every sequence of information frames, and 
that there is a break in the received 
traffic before any new messages are queued 
up for transmission. 


Conseguences of the architecture 


The Pascal implementation on _ the 
HP-64000 development system was not a full 
ISO standard Pascal. The major difference 
dealt with character strings; the HP Pascal 
had a STRING data type whereas the ISO 
standard has only arrays of characters. 
Unfortunately when the HP system writers 


adopted the STRING data type, they threw 
out completely any compatibility with ISO 
standard programs - character strings 


longer than one byte could not be used. 
This problem was ‘solved! by including all 


character strings into one area of memory 
in EPROM. All references to constant 
strings had to reference the name of the 


array containing the data in this read only 
data area. 


The Pascal code was checked out on two 
different computer systems prior to being 
installed on the TAPR board. The systems 
were a 36 bit mainframe and an 8 bit micro. 
The 36 bit mainframe checkout used routines 
to loop back HDLC input and output together 
in software; this allowed the software to 
connect to itself and allowed the basic 
logic to be checked out; alt” 1.6f thas 
checkout was greatly speeded up via the 
symbolic debugger on the mainframe, The 8 
bit micro allowed on the air tests with 
VADCG boards, and was invaluable in shaking 
down more basic logic problems. Again the 
routines to interface to terminal and HDLC 
I/O had to be changed to reflect the 
routines existing in the 8 bit. micro 
system, but this is a pretty easy task to 
accomplish, The result of this staged 
checkout was a very robust implementation 
Of. X25: There were bugs in the Pascal 
code, but they were only evident under 
extreme conditions. 

Implementation of the architecture 

There are four streams of data flow: 
Two directions for HDLC I/O and _ two 
directions for terminal I/O. Knowing when 
there is data present in the input streams 
and when there is enough room in the 


buffers for more characters in the output 
streams is handled by global variables. 
These variables are generally set by 


interrupt routines and reset when low level 
routines called by Pascal manipulate data 
associated by the flags. Each data stream 
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has its own peculiarities, and the flag 
checking/clearing activity associated with 
each peculiarity will be covered. 


The first stream of data is the HDLC 
input stream. Here a global variable 
exists which always contains the upitc input 
top frame size, and is zero if there are no 
HDLC input frames placed into the HDLC 
input buffer and not yet processed by the 
Pascal program. The portion of the Pascal 
code that handles HDLC input notices that 
the variable is nonzero, and calls a low 
level routine which will move the HDLC data 
from the input ring buffer into a private 
Pascal buffer for further examination. 


For “HDLC. - output, there is a global 
variable which contains the number of free 
bytes in the HDLC output ring buffer, This 
cell is checked before any HDLC output 
frame 1S generated, and if there is not 
enough room in the HDLC output ring buffer 
for the potential output frame, then the 
generation ofthe output frame is deferred 
by simply not clearing the flags that cause 
the output frame to be generated. In the 
case of digipeated frames, if there is not 
enough room in the HDLC output ring buffer 
for the digipeated frame, then the 
digipeated frame is simply forgotten. 


Terminal output is similar to HDLC 
output, but there are differences. There 
is a global variable which contains the 
number of bytes currently available in the 
output ring buffer. The routine called to 
queue up terminal data will always wait for 
Space available in the output ring ‘buffer 
to queue the character, The purpose in 
having the variable output ring free byte 
count is to avoid waiting for buffer space 
when X-frames come in on the HDLC input 
port. When an I-frame comes in that has a 
data portion too big to buffer, the data in 
the frame are ignored and the HDLC message 
"RNR" is scheduled for future transmission. 
This async output routine is’ freely 
callable from anywhere within the Pascal 
code, and does get called asa part of 
parameter displays, hex dumps., and internal 
debug routines, It was decided that when 
any of these activities were going on, no 
one would care if the Pascal code was 
spinning while waiting for more room in the 
async output buffer. 


Now we come to the most interesting of 
the buffering problems, terminal input. 
The nature of X.25 is that there can be up 
tO seven complete I-frames in flight at 
once. From the tight RAM limitations, it 
was clear that the input data for these 
I-frames could not be duplicated anyplace 
else in memory. The solution chosen this 
time around was to build a table describing 


the active portion of the terminal input 
ring buffer. The table is eight entries 
long, and each entry consists of a data 


start pointer into the terminal input ring 


buffer, and a data length frem that start 
POUNCE. The table is eight entries long 
because that is the modulus’ for the X.25 


sequence numbers , and these X. 25 sequence 
numbers serve aS indexes into’ the table. 
Part of the routine activity is to check to 
see if a new I-frame can be generated, and 
if sothen a check is made for data to fill 
the I-frame. This checking is performed by 
calling a routine which returns a removal 
pointer anda size for data (if any) 
present within the terminal input ring. If 
there are data present, then the size will 
be nonzero, and another table entry can be 
constructed to describe an P-frame in 
flight. When I-frames get acknowledged the 
data space occupied in the terminal input 
ring buffer is marked no longer in use by 
advancing to the next sequence number and 
by changing a_ pointer , allowing’ reuse of 
the memory. One consequence of this design 
choice on input buffering is a "selective 
reject" (asking for fills) , becomes a more 
difficult job to implement than if the 
other feasible approach of using linked 
lists had been made (It should be noted 
that selective reject is not part of X.25). 


was Simplified by 
the generation of 
transfer. 


The next area that 
the design decisions is 
HDLC frames for information 
There is a definite priority in X.2S5for 
the kinds of frames that have to be sent, 
The priority scheme is implemented by the 
order in which flags are checked. These 
flags are generally set in the HDLC input 
routine, but may be set by anyone to 
schedule HDLC output. The flags that are 
checked and the order in which they are 
checked are: The send RNR flag (set when 


terminal buffer space gets low) to send a 
RNR frame, the send REJ flag (set when an 
out of order frame is received) to send a 


received RNR’ flag must be 
reset (set when an RNR frame is received) 
to send an I-frame, the send RR flag (set 
when I-frame received) to send an RR frame. 


REJ frame, the 


This section of code is also where the 
hal f-duplex decision must be made. The 
code to generate these output frames is 


only executed if the modem signal DCD (data 
carrier detect) is low or if the DCD signal 
dropped after any of the flags scheduling 
RNR, REJ or RR frames were set. This 
simple test is all it takes to prevent the 
sending of an RR frame for every I-frame 
received. Notice also that with the order 
in which the flags are checked, sending an 
I-frame will be attempted before sending an 
RR frame, so that if both sides have 
I-frames to_- send, then there are no RR 
messages sent when an I-frame would also 
acknowledge receipt to the other side. 


Another detail that was made quite 
easy by the "no interrupts in Pascal" 
decision was the handling of multiple 


software timers. Actually, there are only 
two timers, the beacon timer and X.25 timer 
tl, but they are handled exactly the same 
way. The generalized timer code is 
implemented via a Pascal structure; this 
structure contains an expiration time and a 
Boolean flag that indicates whether or not 
the timer iS running. "Time" is used 
loosely, for the only way the Pascal code 
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the passage of time is by 
yet another global variable. 
variable is incremented at 
rate by an assembly 
routine. Whenever a 
started, its expiration 
time is set to the time global variable 
plus the number of seconds in the timer 
interval, and a Boolean flag is set within 
the timer structure to indicate the clock 
is active, The big loop of code that is 
continually checking flags now has to check 
the timers for expiration, and this is 
quite easily done by comparing the global 
variable time with the expiration time in 
the timer ,. 


is aware of 
looking at 

The time global 
a one per second 
language interrupt 
timer needs to be 


Debugging and checkout 


A subset of ISO standard Pascal was 
selected which would work both with the 
HIP-64000 compiler and the two systems that 
I had available for writing and checkout, 
The real reason for this subset decision 
was to allow as much checkout of the 
software as possible in a_e friendly 
environment. The "no interrupt code in 
Pascal" decision made possible the 
replacement of low level routines in 
assembly language with routines written in 
Pascal which could invoke standard Pascal 
I/O. On the mainframe, a dummy set: of HDLC 
input and output routines was written to 
loop back the HDLC output internaily (from 
the Pascal programs point of view) to the 
HDLC input. On the 8 bit micro system, 
existing routines for MDLC input and output 
were modified to use new calling sequences 
and the Pascal code was actually executed 
on the air. In both debugging testbeds, 
the clock was simulated by incrementing the 
global variable holding the second tick 
whenever the code in the main loop noticed 
the system time of day change froma 
previous’ value. These sets of routines 
allowed checkout of the major logic flow of 


the Pascal software under a symbolic 
debugger, This self-test arrangement was 
extremely valuable, and allowed about 


ninety percent of the bugs in the Pascal 
code to be eliminated under the friendly 
environment of the symbolic debugger. Not 
everything could be checked, and the things 
that could not be checked were not: setting 
flags for the low level routines (which 
didn't exist) or missing transitions in the 
state/event table that were never exercised 
during this self-test. One clear fallout 
0 f the debugging procedure was 
transportability, because the software was 
running on two different Pascal systems 
before the TAPR TNC software even net the 
TAPR TNC hardware. 


Summary 


The broad design decisions that were 
made before implementation of the TAPR TNC 
software served as an a id in 
inplementation, supplying a framework that 
wcould support the detailed coding process. 
These decisions were made in the light of 
previous experience (and mistakes) in the 


implementation of three other systems 
Similar O- 2.25. There were other choices 
that could have been made to supply the 
implementation framework, but my intent was 
to illustrate the decisions which made the 
TAPR INC software almost write itself. 
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Unique Features of the TAPR TNC 


by Lyle Johnson, WA7GXD 
c/o Tucson Amateur Packet Radio Corp 
P.O. Box 22888 
Tucson AZ 85734 


Background 

The Tucson Amateur Packet Radio 
(TAPR) Terminal Node Controller’ (TNC) 
began as a _ local. project done by a 
handful of Tucson-area Amateurs late in 


1981. The project attracted enough 
attention to cause the formation of a 
formal club as well as an enlarged number 
of participants. As interest continued 
to grow, TAPR incorporated as a_ non- 
profit R&D group, and the TNC project 
changed from a local effort to include 
active participation in the design, imple- 
mentation and testing phases with Amateurs 
from the West Coast to the Northeast. 


The original Alpha-level TNC, of 
which only a dozen’ kits were distributed, 
led to the development of the _ current 
Beta-level TNC, now undergoing testing in 
dozens of sites, with site sizes ranging 
from three to over twenty stations. The 
total Beta distribution is approximately 
175 preassembled TNCs. 


While there have been, and continue 
to be, many other methods of getting 
involved with Packet activity, the TAPR 
TNC offers a number of unique features 


that are worth noting. .It is the intent 
of the author that this paper’ accent 


those features, and it is the hope of 
TAPR that other exnerimenters may benefit 
from the experience and insight gained by 
the TAPR effort. 


System Design 


The TNC was designed as part ofa 
system to allow an individual Amateur 
station to operate using the Packet mode 
with a minimum of integration problems. 
To this end, the required radio and term- 
inal/eomputer interfaces are as_ general 
as possible. All I/O areas of the phys- 
ical PC board surround a user wire-wrap 
area to allow for custom configuration. 
Further, the wire-wrap- section has all 
significant power supply rails bordering 
one side. 


Since it was designed as a system 
component, a radio-oriented MODEM (modu- 
lator-demodulator) is included on-board. 
To minimize the software design effort 
that might otherwise be required, an on- 
board microcomputer was designed to handle 
all aspects of lower-layered protocol 
implementation, with special emphasis in 
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hardware to allow operation in an Amateur 
radio environment,. 


In any microprocessor- based device, 
software 1S a very important consider- 
ation. Consistent with the TAPR philosophy 
of modular flexibility, considerable 
efforts were made in hardware designto 
accomodate the desires of the software 
groups. Parallel software efforts were 
made, with the Pascal-based implementation 
of the "standard" protocol adopted in 
Washington on October 19, 1982, being ini- 
tially distributed with the Beta TNCs.A 
FORTH- based design, implementing a dy- 
namic addressing level-two protocol, -is in 
process of being integrated on the TNC for 
the Beta testing phase. 


Without proper documentation, most 
equipment is either rendered useless, or 
requires an inordinate amount of operator 
interaction to discover its "secrets." 
TAPR determined early on _ to provide as 
complete a manual set as was practical. 


Finally, since it is generally con- 
ceded that Packet radio is in its infancy, 
the TNC design group made particular 
efforts to ensure flexibility as wellas 
capacity for expansion. 


MODEM Design 


The MODEM incorporated in the TNC is 
designed for compatibility with thede 
facto standard Bell 203 tone pair, 1200 
and 2200 Hz, using simple AFSK at a maxi- 
mum data rate of 1200 baud. 


The tone generator is” straightfor- 
ward, using the Exar 2206 FSK IC in a low- 
distortion, sine-wave configuration. The 
output is buffered by a simple +1 op- amp 
circuit, then ac- coupled to the radio 
interface connector. The output amplitude 
is user settable via a twenty- turn 
trimpot over a range from millivolts to 
volts. 


During early experiments with the 
TNC, it was discovered that the WD 1933 
HDLC controller did not allow direct 
control of the output state of its Tx Data 
pin when used in the NRZI mode. This com- 
plicated the issue of the US-required CW 
identification. In the end, use was made 
of the Exar 2206's analog multiplier input 
to allow for tone on-off keying of the CW 
ID. This input is buffered by a TTL inver- 


ter, asiowing the tone state to be set 
under software control, independent of any 
other MODEM parameter. 


The tone generator frequencies are 
easily changed via adjustment of indi- 
vidual twenty-turn trimpots. To facilitate 
such adjustment, the TYC hardware in- 
cludes, and the present software supports, 
a frequency counter. This is a_ program- 
mable 16-bit counter/timer u s e ly the 
calibration routines as a period measure- 
ment timer. The software is designed such 


that the user may calibrate alnost = any 
frequency within the range of 10 Hz to 
over 230 kHz. The resolution is +/- 1.98 


uSecs (one cycle of the system master 


clock of 921.6 kHz). 


Although not strictly a MODEM func- 
tion, control of the transmit control line 
is a necessary feature of the radio trans- 


mitter interface. To help prevent a 
"glitch" from allowing the TNC to lock up 
a radio frequency by continual assertion 


of the transmit control line, a monostable 
multivibrator, or "one-shot", is in series 
with the software- controlled transmit 
command line. A time constant of about 14- 
seconds allows a multiple- frame Packet 
transmission at the "normal" VHF packet 
rate of 1200 baud, along with a CWID ofa 
typical Amateur call sign at 20 WPM. The 
particular circuit implemented utilizes a 
555 timer IC in a non- retriggerable con- 
figuration. Non- retriggerable simply 
means that the 14- second timeout can't be 
held “on" by a continuous input -- the 
input must be removed before the 555 will 
accept another trigger. Thus, a_ Packet 
"channel" i s protected from a_ runaway 
transmitter with minimal impact on system 
performance. 


On the receive side, an Exar 2211 
phase-locked loop (PLL) FSK demodulator 
is used. This circuit has a wide dynamic 
range input circuit (3 mV to 3-volts), and 
features both data and "carrier detect" 
outputs. (Note that the carrier’ referred 
to is the audio subcarrier, not’ the rf 
carrier.) 


The circuit parameters have been 
optimized for operation at a data rate of 
1200-baud, utilizing simple FSK with tones 
of 1200 Hz and 2200 Hw. After initial 
design, extensive testing was conducted 
and the circuit values "tweaked" for best 
operation. A few problems cropped up that 
may be of interest to others experimenting 
with similar MODEM designs. 


The XR2211 chip is very sensitive to 
amplitude differences of the two input 
frquencies greater than about 3 db. At 6 


db, the PLL will take so long to lock as 
to render the channel inoperative at the 
desired baud rate. Specifically, TAPR 
found that a typical 2-meterFM  trans- 
ceiver would not operate reliably above 


about 450 baud with the XR2211used in an 
uncompensated circuit, while 1200 baud was 
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in a compensated. one. 
Various means of compensation were tried, 
and the best appeared to. be an active 
filter. A CMOS switched capacitor filter 
was implemented, with a DIP header car- 
rying the resistor network needed to con- 
figure the filter for a particular radio. 
The DIP header allows’ easy reconfigur- 
ation. This design is presented in detail 
in another paper in these proceedings. 


easily realized 


means of operator 
level setting 


In addition, a 
feedback for receiver audio 
was deemed desireable, to prevent over- 
loading of the filter while maintaining 
sufficient audio to prevent serious degra- 


dation of the s/n ratio. This was imple- 
mented with a simple back- to- back LED 
pair between the audio input buffer (a 


-10 amplifier) and the filter input net- 
work. Initial results from the field 
indicate this method to be both easy to 


use and effective. 
Microcomputer 


The TNC uses a 5809- based controller 
for logic implementation. This is believed 
to be the first, Amateur radio application 
of the 6809 apart from individual efforts. 
The architecture of this microprocessor 
(uP) lends itself readily to high level, 
block-structured programming environments, 
and the first cut of TNC’ software is in 
fact written in Pascal. 


The memory subsystem of the TNC util- 
izes a six- site bank of 2% pin sockets 
configured in the JEDEC "two line control” 
bytewide standard. This means’ that RAM, 
ROM, EPROM and/or EEPROY may occupy any 
socket. In addition, the memory may occupy 
any integral multiple of 2k-~ bytes cap- 
acity. To allow for future memory devices 
of greater density than used in the cur- 
rent TNC configuration, the memory map was 
carefully planned and executed in a bi- 
polar Shottky PROY decoder. 


The initial TNC consists of 6k~ bytes 
of RAM contiguous from address 9, 4k- 
bytes of I/O space starting from address 
2000H, and 24k- bytes of EPROM contiguous 
from address QAO00H through OFFFFH. 2k- 
byte RAMs are used, along with 8k- byte 
EKPROMs. Rk- byte RAMs can_ easily ' be 
accomodated, and 15k- byte and_ larger 
EPROMs can be used with a simple one- pin 
jumper (the socket wiring is presently 
compatible with 2764 and smaller EPROMs -- 
the one- pin change will make them compat- 
ible with 2764 and larger EPROMs). One 
Beta tester is building a_ piggyback 
adapter to utilize all 64k- bytes of add- 
ress space. 


Another unique aspect of memory 
design is the incorporation of the Xicor 
NOVRAM. This is a 256-bit device that can 
be accessed as a normal RAM (access time 
390 nSec) as well as a 5- volt only 
EEPROM. This allows the user to store such 
parameters as station call sign, serial 


HDLC port parameters, 
etc., and have the information retained 
after power is removed. However, the user 
can also change these parameters inter- 
actively. This provides a_ significant 
degree of freedom for the operator / 
experimenter, and is believed to _ be a 
first in Amateur radio. 


port parameters, 


Software Considerations 


The Beta TNC is designed to support a 
variety of protocols by virtue of its 
large address space and third- generation 
UP. The initial Beta release software, 
discussed in much greater detail elsewhere 
in these proceed ings, was designed to be 
compatible with the existing “Vancouver” 
protocol as well as implementing the lower 
layers of the AMRAD sponsored “AX. 25" 
protocol adopted by the major US Packet 
aoe in Washington, DC, on October 10, 
1982. 


The software package produced _ not 
only supports these modes, but it also 
supports operation of the TNC as a digi- 


peater under either of the two protocols 
as well as a beacon under either’ proto- 


col). The TNC can in fact be used as all 
three of the above devices simultaneously, 
the only limit being that all functions 
must be under either one or the other of 
the two supported protocols, but not both. 


Further, the software package sup- 
ports certain powerful trace and debugging 
modes, which have proven to be of extreme 
value during system troubleshooting. 


Other Features 


The TNC design provides for software 
configuration of nearly every parameter 
associated with the I/O ports. For the 
serial (RS-232) channel, these parameters 
include baud rate, number of stop bits, 
parity options and data word length. For 
the HDLC port, the baud rate is under 
software control-, using a 16-bit program- 
mable timer. This allows using nonstan- 
dard data rates, such as the 490 baud 
being considered for experiments on the 
upcoming Phase 3B AMICON channel. 


The parallel I/O port, to be sup- 


ported in an upcoming revision to the Beta 
test software, is a full handshaking par- 
allel interface, with separate S-bit chan- 
nels for input and output . Further- , an 
EPROM programming adapter is being readied 
to allow users to bootstrap themselves 
along in software development and distri- 
bution. 


Documentation 


The TNC Beta document is a very com- 
prehensive manual, oth of the TAPR TNC in 
particular and Packet radio operation in 
general. 
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Over 140 pages in length, it includes 
chapters on setting up, operation and cal- 
ibration, as well. as in- depth discussions 
of the hardware, protocol and system de- 
sign. It sets a standard seldom seen in 
manuals accompanying very expensive Ama- 
teur equipment, and far exceeds what many 
have come to deplore as "manuals" for the 
more common Amateur radio devices, 


The Beta Test manual is currently in 
a State of rapid expansion as reports come 
in from Beta Test sites. The eventual man- 
ual will include expanded appendices with 


detailed information on interconnection 
with a plethora of commonly used &meter 
FM radios, as well as' hardware and soft- 
ware installation data for many _ personal 
computers and terminals. The intent is to 
provide sufficient detail to allow a non- 
technical Amateur to successfully bring up 
a Packet radio stat ion without other 
assistance. 


Beta Test 


Perhaps the most unique feature of 
the TAPR TNC is the manner in which it is 
being tested. Many innovative Amateur 
devices have been built as a result ofa 
club project, involving perhaps 29 or 39 
units. Commercial interests often build 
prototype units and allow selected cus- 
tomers to test them, who then offer feed- 
back for the final production release of 
the product in question. 


When TAPR decided to go ahead with 
the TNC design and implement it, the mail- 
box was full of requests from  An?ateurs 
desiring to be included in the initial 
distribution. Realizing the tremendous 
resource represented by these eager par- 
ticipants, and recognizing that the ‘local 
Tucson "cOre" would’ be hard-- pressed to 
fully shakedown, test and debug the TNC in 
a reasonable time frame, the decision was 
taken to allow a_ fairly large numberof 
TAPR membders the opportunity to contribute 
to the TNC designeffort by providinga 
test bed. 


The participants were informed that 
this was to be a test in ‘both word and 
deed, and that all Beta testers were ex- 
pected to file formal reports via Beta 
Test Coordinators to be locatedin each 
area. Further , to make the test sites as 
autonomous a s_ possible, each local site 
was to determine its own coordinator. 4 
network was established that now spans the 
USA. and reaches, via AMSAvT- sponsored 
participants, to Asia, Africa, Europe and 
Oceania. 


Beta sites were to include both tech- 
nical and non-technical Anateurs, and were 
to be self-suffcient as to support, modi- 


fication, repair and updating of the TNCs 
within the site. It was felt that this 
would both relieve the pressures on the 


Tucson group and provide qa _ reasonable 
cross-section of Amateurs with regard to 


variation, 


technical expertise, climatic 
(jammers and 


rfi and frequency congestion 
the like) . 


Further, by using this method, it was 
believed that a maximum number of Amateurs 
in varied locations would be exposed to 
the raucaus noises generated by the packet 
frames, and inquiries would lead to fur- 
ther interest in the mode. Alocal group 


could then "spread the packet gospel” and 
help ensure the further growth of the 
mode, even while it undergoes’ changes 


associated with its infancy. 


Finally, many people who contacted 
and continue to contact us, indicated 
that there seemed to be no cohesive force 
amongst packeteers, nor central clearing 
point for information. TAPR has therefore 
attempted to fill this void, and_ the 
results to date have been most gratifying. 
By making Beta Test a national endeavor, 
participants are able to become involved 
in a_ broad- based, grassroots packet 
effort. By providing support for the TNC, 
people are reassured that, in the event 
they face real problems, there is a source 
for technical assistance, both in hardware 
and software. 


us, 


The Beta Testing of the TAPR TYC is 


still in its initial phase, that of dis- 
tribution. As of this writing, over 110 
of the scheduled 170 TNCs have been 
shipped to a number of sites scattered 


across America. Yost sites have had little 
trouble getting the TNCs on-the- air. Many 
radios, terminals and personal computers 
have been successfully interfaced. 


Already, defect reports are coming 


A few significant hardware bugs have 
and work has commenced on 


solving the problems. Software- related 
problems have been reported, and the 
second release of Beta software will be 
appearing around the time of this confer- 
ence. 


in. 
been noted, 


It is believed by the author that 
this level of testing and cooperation has 


not been seen in Amateur radio before. The 


Beta Test participants have been very en- 
thusiastic, as well as patient and suppor- 


tive of the entire effort. 


Conclusion 

The TAPR TNC includes a variety of 
unique and innovative circuits, concepts 
and ideas. It is designed for both the 
technically inclined experimenter , for 
whom it offers a host of features accen- 
ting flexibility and expandability, as 


well as for the less- technically inclined 
operator, for whom it offers ease of oper- 


ation. 


The documentation of the TNC is at a 
level uncommon in Amateur radio, with a 


depth and breadth seldom seen outside of 
professional circles. 
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The initial software release 


incor- 
porates many advanced features to allow 
the experimenter great latitud opti- 


in 
mizing system parameters, as well as flex- 
ibility 1n his particular system config- 
uration. Compatibility with both the *‘Van- 


couver” and the "AX.25" protocols is pro- 
vided. 


__. The method of Beta Test is unique 
within Amateur radio endeavors, and is 
designed both the enhance the TNCs suit- 


ability for Packet radio use as well as 
increase the exposure of the general Ama- 


teur community to the strengths an 


fits of this mode. a 
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ABSTRACT 
This paper describes work underway 
within AMSAT to define modulation, 
channel access methods, and related 
system-level considerations in the 


design of the store-and-forward packet 
radio satellite known as PACSAT. 


This is not intended as a comprehensive 


design specification, primarily because 
one doesn't yet exist! In particular, 
only those decisions primarily 


concerning spacecraft hardware design 
are emphasized here, since the details 
of control algorithms, protocols, etc, 
will reside in software capable of being 
changed and reloaded into the onboard 
computer(s) after launch. 

1. Orbital Considerations 

PACSAT is intended to operate ina low 
altitude, polar orbit with the special 
characteristic that the satellite is 
accessible from any point on earth at 
least twice every day, at about the same 
local time each day. These so-called 
"sun synchronous" orbits are frequently 
used by weather and earth resources 
missions. Oscars 6, 7, 8 and 9 are all 
in sun synchronous orbits, SO many 
amateurs are already familiar with them, 


The low altitude and relatively high 
velocity of such a satellite has several 
implications for communications: 


earth locations, a 
two or three passes 


1. For most 
sequence of 
occurs twice daily,a 5s 


earth carries the station through 
the orbital plane every twelve 
hours. 

2. Coverage at any given time i s 
relatively small and continuously 
changing. A geostationary 
satellite "sees" a fixed portion 
(41%) of the earth's surface, B y 
comparison, Oscar-8 covers all 


points on earth at least twice per 
day, but when it is directly over 
the north central US, it can only 
see North America. 


the turning 
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3. Passes are short. A typical pass 
may last for only 15 minutes from 
horizonto horizon. For digital 
communications, the highest 
possible bit rate is desirable to 


maximize the amount of 
communication that can be carried 
during a pass, although for 
operational flexibility the 


spacecraft downlink transmission 
rate will be under the control of 
a command station. 


4. Path losses are modest, 
approximately 25-30 dB lower than 
to geostationary satellites. This 
may allow the use of lower 
transmitter power, omnidirectional 
antennas, or less efficient 
modulation techniques, all of 
which help reduce costs. 

5. Doppler shift is significant. At 


70 cm, hor izon-to-hor izon Doppler 
shift can be as much as plus or 
minus 10 khz, requiring some for 
of automatic frequency tracking 
for optimum pecformance. Extra 
wide receiver filters ans 
noncoherent dewodulation will 
tolerate Doppler shift, but atthe 
cost of reduced performance. 


6. Propagation time is short, ranging 


from 3 milliseconds when the 
satellitei s overhead to 12 
milliseconds on the horizon. 
Therefore, a communication 
protocol requiring close 
interaction betweenthe satellite 
and itsS users would not unduly 
penalize performance except for 


very small packets. 


2. Downlink Margins 


designing a communications 
there are always practical 
power, size and weight, 


In 
spacecraft, 
limitations on 


often with the emphasis on power. 
Hence, the power available for the 
spacecraft transmitter becomes the 
limiting factor in the overall system 
design. For this reason, it is helpful 
to Start our analysis with a= stated, 
realistic value. This immediately 
provides insight into the range of 
modulation and bit rate options 


available, therefore, AMSAT 's best 
estimate of RF output power for PACSAT 
is P-2 watts. 


For aspacecraft in an Oscar-8 orbit 
(altitude 900 km), path loss ontwo 
meters would vary from 135 dB when the 
satellite is directly overhead to 147 dB 
with the satellite o n the horizon, a 
range of 12 dB. Since even during an 
overhead pass the satellite spends’ most 
of its time “nearer” the horizon than 
directly overhead, we will be 
conservative and use the horizon figure 
in subsequent calculations. 


Given that approximately 1 watt of 
transmitter output power is available on 
2 meters, ard that omnidirectional 
antennas are used both on the space-rraf t 


and on the ground, receiver- input powel 
would be -147 daw (-117 dBu, or .3 
microvolts into 50 ons.) A receiver 
with a bandwidth of 15 khz and a nois»= 


temperature of 300 K would generate an 
equivalent. input noise powerof -162 


dBW, for a carrier-to-noise ratio of 15 


GB, adequate for a low bit error rate 
with virtually any digital modulation 
scheme. However, since the satellite 
will move rapidly, use a real antenna 
with unavoidable pattern nulls, and 
oftenpass behind such real-world 
obstructions as trees and hills, 


additional margin is desirable. 


This could be achieved in several ways, 
by 


1. Reducing the receiver bandwidth. 
Each factor of two reduction would 
improve the carrier-to-noise ratio 
figure by 3 dB. However, for a 
given typeof modulation, this 
reduces the bit rate, which is 
undesirable because it limits’ the 
amount of traffic that can be sent 
during the relatively brief 
passes. 


2. Using more sensitive receivers. 
It 1S now quite easy to _ find 
inexpensive preamplifiers with low 
noise figures. However, external 
noise then becomes a factor, 
limiting the degree of improvement 
possible. 


3. Using gain antennas with automatic 
track ing. Techniques for this 
have been experimented with by 
AMSAT members for several years, 
and soon will be within the realm 
of the average user of the Phase- 
3B spacecraft 


Although the computation of 
antenna pointing angles has become 
very easy (the AMSAT ZX 81 project 


uses that very inexpensive 
personal computer for the task), 
the gain antennas are still 


relatively large and require fixed 
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locations. We should therefore 
require gain antennes only as a 
last resort, in the sense that it 
should be possible to make 
effective use of PACSAT wit hout 
them. 


efficient modulation 
There exist techniques 

give much better 
performance in the presence (Of 
noise which are not yet widely 
used in the Amateur service. Many 
of these techniques’ have been 
widely used in commercial 
terrestrial and satellite 
services, but until now, they have 
often been considered out of reach 
of the average amateur because of 
cost and complexity, However, 
advances in digital electronics 


4. Using more 
methods. 
which can 


has de-coupled the issue of eost 
from complexity, bringing these 
techniques within reach of the 
average amateur. 
38. Modulation Alternatives 
We feel that the modulation method 
chosen 1S a crucial elernent of the 
PACSAT design, and I will spend the next 


part of this paper evaluating our 


alternatives. 


3.1 AFSK-FM 

Audio frequency frequency--shift-keying 
on an FMcarrier is the’ technique 
currently in widespread use fOr 


terrestrial amateur packe- radio, with 
the Bell 202 modem frequencies (1200 and 
2200 hz) a de-facto standard. Inthe 
amateur- satellite service, JUOSAT-Oscar-9 
uses bit-coherent A¥SX-FM for itsVHE 
and UHF telemet ry, wit h tone f requenc ies 
of 1200 and 2400 Hv-- close enough to 


those of the Bell 20? to allow the use 
of that (noll-coherelt and therefore 
non- opt imum) modem by the majOrity of 


stat ions receiving telenetry. 


AFSK- FM has several mujor advantages:i t 
is cheap, simple,and allowsthe use of 
general-purpose transceivers without 
mod: f icat ion. Doppier tracking Is 
relatively easy, since most amateur FM 
receivers have suff icier-t bandwidth to 
allow large frequency deviations (e.g,1l 
khz) without signif icant degradation of 
bit error rate, and the modulation tone 
frequencies are not directly affected by 
Doppler shift. 


Despite its simplicity, however, AFSK-FM 
has serious disadvantages for satellite 
use, which rule out its use in PACSAT: 


1. Inefficient bandwidth utilization. 
A 15 khz channel is used by UOSAT 
to carry a (maximum) 1200 bps data 
stream, abandwidth density of 
only .08 bits/hertz. Particularly 


in the 2 meter band, spectrum 
efficiency is an important 
consideration. 

2. Poor noise’ performance. Since 


AFSK-FM is essentially doubly- 
modulated F M , it exhibits a very 
sharp noise threshold at a 
relatively high carrier-to-noise 
ratio, and suffers greatly from 
impulse noise. Subjective 
experience with receptionof the 
350 milliwatt 145,825 MHz UOSAT- 
Oscar-9 telemetry beacon shows 
that pulse noise,e.g., from power 


lines, causes Signif icant errors 
even at signal strengths otherwise 
sufficient to cause “full 
quieting” in the baseband FM 
channel. Local impulse noise and 
fades be low threshold due to 
spacecraft rotat ion and 
polarization losses cause many 
errors, despite a_ theoretically 


good link margin. 
3.2 FSK 


Although in common use on the HF amateur 


bands, “straight“ frequency shift keying 
(FSK or Fl) has not yet core into 
widespread use _ on the higher frequency 
bands. FSK at VHF can be’ implemented 
with simple modif icat ions to most 
convent ional VHF-FM transceivers; a 
direct input to the modulator anda 


slicer onthe discriminator output is 
required. The spectral efficiency of 
FSK can be as high as 1 bit/Hz; for our 
working bandwidth of 15 khz, FSK could 
realistically support a data rate of at 
least 10 kbps. 


The Bell System’s Advanced Mobile Phone 
Service (AMPS:, uses NBFM voice 


transceivers with 8 khz peak deviation, 
30 khz IF bandwidth, and discriminator 


detection to carry a biphase-encoded 10 


kbps FSK signaling channel. In bipkase 
encoding, the data stream is exclusive- 
ored with a clock at the bit rate, 
resulting in a signal with no DC 
component whose energy is concentrated 


about a frequency equal to the bit rate. 


This allowsa n “indirect FM” (phase 
modulated) transmitter to be — used, 
provided an integrator is inserted 
between the bi-phase encoder and the 
modulator. This is a direct adaptation 
of FM techniques used to encode data on 
disks and high-density magtapes. Since 
in FM the baseband (demodulator output) 
noise level increases with increasing 
frequency, a practical limit to the bit 
rate exists requiring relatively high 
receiver input C/N ratios when operating 


at high rates. In AMPS, considerable 
retransmission redundancy is also 
not 


provided since multipath fading, 
gaussian noise, is the primary source of 
errors in mobile radio. 
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AMPS is evidence that high rate FSK is 
practical given a sufficient C/N ratio. 
Performance would be better with PACSAT, 
since multipath fading is less severe in 
satellite channels than in terrestrial 
mobile radio, except when the satellite 
is near the horizon. For Our working 
C/N figureo f 1 5 dB, noncoherent 
reception of FSK (e.g., with an ordinary 
F'm discriminator) would prov idea 
theoretical bit error rate of about 
107% acceptable, but with little 
margin for impiementat ion losses and 
fading. For example, if C/N dropped to 
12 dB, the bit error rate would jump’ to 
ox L0°=4, 


Because of the tight C/N margin, Doppler 
correction is required in order to allow 
narrow receiver bandwidths no wider than 
the signal. Since biphase encoding 
produces no baseband DC component , 


Doppler could be tracked by a simple 
integrator connected to the 
discriminator output. 

We canrule out use of noncoherert FSK 
modulators for PACSAT, because it will 
be shown later that another modulation 
techn ique (MSK) exists which is 


compat ible with simple FSK demodulation 
but also allows coherent detection with 
a 3.5 - 4 dB improvement’ in bit error 
rate. However, our analysis of 
noncoherent FSK is useful because it 
indicates the performance that could be 
expected if MSK is demodulated witha n 
FM receiver. 


t3 


Dif ferent ial Phase-Shi f t Keying (DPSK) 
lis relatively new to amateur radio, but 


DSPK 


will be used by AMSAT for the Phase IIfl 
spacecraft engineering beacon. DPSK has 
significant advantages :it is fairly 
bandwidth efficient, works very well in 
low carrier-to-noise levels, and can 
automatically track Doppler shifti f 


correctly designed. 


DPSK is actually a modified form of true 
PSK in that the change (or- lack thereof) 
in carrier phase between each bit 
interval is used to determine the output 
state. In true PSK, the absolute phase 
of the carrier during each bit interval 
determines the output state, which 
requires an absolute phase reference a: 
the receiver. If a crock is. derived 
from the incoming data stream, there 
would be a 50-50 chance that the 
receiver would synchronize 180 degrees 
from the correct value, resulting in a 
100% bit error rate! Differential PSK 
avoids this problem at the cost of 
hav i ng channel errors “propagate” 
through successive bits. However, in a 
packet environment where only a single 
bit error is needed to cause rejection 


of apacket and retransmission, extra 
errors “caused" by the first are of no 
consequence. 


The noise performance of DPSK is 
considerably better than conventional 
FSK; for our 15 dB reference C/N, the 
bit error rate would decrease to 10*-10. 
However, the real advantage would be 
under marginal conditions: the bit error 


rate would not increase to 5 x 10%-4 
until the C/N ratio had decreased to 
about 9 dB. Withina 1 5. kHz bandwidth 


DPSK could carry 15 kbps, although its 
noise performance would be degraded by 
such tight filtering; 9600 bps would be 
more realistic. 


AMSAT has considerable experience with 
DPSK modulators and demodulators 
designed for 400 bps telemetry reception 
from Phase 3-B. Experiments have shown 
that non-linear transmitters are OK, and 
that 2.4 khz SSB transceivers are fine 
as long aS compensationis made for the 
nonlinear phase response characteristic 
of SSB IF crystal filters. 


The Phase 3 telemetry decoders use 
Costas loop carrier recovery which 
provides optimal performance, 


but may 


take an excessively long time to lock up 


ina multi-access packet environment. 
However, very simple DPSK demodulators 
exist that require no clock recovery 
circuit and are able to lock up in 
essentially a single bit time. These 
methods work at the expense of noise 
performance; the figures quoted above 
refer to this form of demodulation, 
while the Phase 3 demodulators do 
somewhat better. 


NASA has also made extensive use of low 


cost, low-speed, (100-400 bps) doppler- 
tracking PSK systems with low altitude 
satellites for applications including 
remote data collection and search-and- 
rescue. 

3.4 MSK 

Minimum Shift Keying (MSK)i s a hybrid 
of FSK and PSK. It can be regarded 
either as coherent FSK with a_ shift of 


exactly one-half of the data bit rate, 
as PSK where the modulating waveform 


or 
is a triangular ramp produced by 
integrating the binary input signal. 


Another equivalent way to look at MSK is 
as quadrature PSK (PSK with four 
possible phases instead of two) in which 
the quadrature channel carries the same 
data as the main channel but delayed = 
one-half bit period. In fact, the usua 

method for optimally decoding MSK 
involves building two PSK demodulators 
with combining circuitry; clearly this 
is more involved than a simple PSK 
demodulator. 


One of MSK's advantages over PSK is that 
is requires minimal filtering to reduce 
its bandwidth to the minimum required. 
It has a constant envelope amplitude, 
unlike bandwidth limited PSK, allowing 
it to pass through a real-world linear 
spacecraft transponder with minimal 
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to other 
through 
Class C) amplifier 
and 
that 
other 


intermodulation distortion 
signals, It can also be passed 
a nonlinear (e.g., 
without the envelope distortion 
resultant bandwidth-spreading 
occurs with DPSK signals. The 


advantage of MSK, perhaps the major one 
for our application, is that it can be 
decoded with simple noncoherent FM 


discriminators with a theoretical 3.6 dB 
loss of noise performance. 


Optimally decoded MSK and PSK have 
almost the same performance in the 
presence of Gaussian noise. However, 
MSK has a significant advantage over PSK 


in cases of adjacent channel 
interference, due to MSK's smaller 
bandwidth. Tighter IF filters can be 


used with less performance degradation, 
and it should be easier to attain a rate 
of 15 kbps in. our 15 khz bandwidth. 
Differential decoders eliminating the 
need for carrier recovery, similar to 
those mentioned earlier for DPSK, exist 
for MSK but are not as simple. 


3.5 Discussion: MS K_ vs. DPSK 


The "votes" are not yet all in among the 
PACSAT system definition and design 
team, although we have narrowed the 
choice to one between DPSK and MSK. 
MSK's most significant advantage is 
clearly its compatibility with simple 
noncoherent demodulators such as an FM 
discriminator,, However, this penalizes 
those who want to "do it right", as 
optimal demodulation of MSK essentially 
requires building a PSK demodulator 
twice. 


could go with a form of DPSK 
essentially similar to that used by the 
Engineering Beacon on_ the Phase 3 
spacecraft, except ata higher bit rate. 


We 


While there is strong interest in MSK 
for AMICON (Phase 3) data 
communications, the relatively short 
time available to settle major 
hardware-related PACSAT issues could 
cause us to choose the Simpler 
technology, i.e., DPSK. While the FSK 
demodulator compatibility feature is no 
Goubt attractive, optimal demodulators 


for PACSAT would be produced by AMSAT on 
a relatively large scale, and _ would 
probably be a small fraction ($50 - 
$100) of the total station cost. 


Either method would provide means _ for 
Doppler correction. The Phase-3B 
telemetry receivers use Costas loop 
demodulators for the DPSK signal, 
generating as a byproduct a correction 
voltage indicating the offset of the 
downlink carrier. This correction 


voltage can be taken out of the receiver 
and applied with the appropriate amount 
of gain to the transmitter, tuning its 
frequency to compensate for uplink 
Doppler. While the uplink channel 
demodulators will probably be able to 


track out the frequency shift without 
correction, we feel that minimizing 
channel lockup time is important enough 
that correction should be provided. 


4. Access Conflict Resolution 


PACSAT will be a multi-access satellite, 
intended to serve a number of users 


simultaneously attempting to send 
messages to the satellite. The downlink 
transmitter will b e connected to the 
onboard computer, not directly to the 
uplink receiver as in conventional 
"bent-pipe" satellite transponders. 


Despite the short propagation delay, 
users will not be able to monitor the 
immediate status of an uplink channel by 
listening t oo 
busy sending down a message intended for 
another user. Therefore, provisions 
must be made to resolve uplink access 
conflicts. (Naturally, since only one 
transmitter, the satellite, transmits on 
the downlink, access resolution is 
relevant only for the uplink.) 


Assume for the moment that the satellite 
traffic will be "balanced", that is, the 
amount of traffic successfully received 
at the satellite will be approximately 
equal to the amount of traffic sent back 
to the ground when averaged over a 
sufficiently long period of time. [It is 
agreed that this 1s an unlikely 
situation, which would only be true if 
PACSAT were to be used exclusively for 
point-to-point communications. Repeated 
transmission of the same information 
from the satellite (e.g., broadcast 
bulletins or spacecraft telemetry) would 
disproportionately increase downlink 
loading. However, it 1S my assertion 
that a balanced traffic assumption is a 
useful one, aS it represents a "worst 
case” for system design. 


All known methods which resolve 
contention between multiple uplink 
transmitters require overhead, and hence 
more bandwidth, than downlink 
transmissions for which there is only a 
single transmitter. We are therefore 
tentatively planning to use the 70 cm 
band, which has’ a 3-Megahertz Amateur 
Satellite Service allocation (435-438 
MHz), for uplink transmissions to PACSAT 
and the smaller 2 meter band segment for 
the downlink. 


In the following sections, I will 
describe two possible access methods for 
PACSAT, and compare their’ relative 
merits. 


4.1 Pure Aloha With Multiple Uplink 
Channels 


The Aloha method calls for each station 
to transmit at will, without concern to 
interference with other’ transmitters. 
(Since stations communicating with a 
satellite are usually far enough apart 
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the downlink, as it may be 


t oO prevent them from hearing each other, 
not much is gained by listening on the 
uplink frequency.) The well-known 
maximum theoretical throughput of an 
Aloha channel, above which delay time 
rises without bound, is 18%. 


A very simple and attractive scheme 
therefore appears. If it is desired to 
balance uplink and downlink capacity, 
S1xX uplink channels (6 x 18% = 108%) 
could be provided. Each one is "equal" 
to the others and scanned rapidly enough 


b sy the spacecraft's onboard computer to 


allow simultaneous reception, at least 
for a time, on all six. A uSer_ station 
would select one of the six uplink 
channels essentially at random whenever 
it has traffic for the satellite. Since 
the channels are all equivalent, all 
that matters is that the stations 
distribute their traffic across the 
channels in order to level out loading. 
This could be accomplished s imply by 
allowing each station to choose an 
uplink frequency at random, changing it 
as often as desired, perhaps with each 
transmission. It can be shown that with 
a sufficient number of stations, traffic 
will tend to become evenly distributed 
over the channels. 


It should be pointed out that to provide 
flow control, a requirement independent 
of the accesS method chosen, the 
spacecraft a n d_- ground computers will 
follow a synchronized "handshaking" 
protocol once a_ traffic transfer starts. 
If the ground computers are “pat ient” 
enough, that is, they allow enough time 
for processing and queuing delays aboard 
the satellite, collisions would result 
only when new stations initially access 
the satellite. 


In addition to providing flow control, 
the go-ahead messages’ to each stat ion 
could include a “recommended” uplink 
channel to _ use. Based on channel 
loading statistics kept in the 
spacecraft computer, the ground stat ion 
would still be free to use any channel 
it wished, although following the 
recommendat ion would improve uplink 
traffic distribution. 


4.2 Reservation Aloha 


The "anarchy" of the Aloha system could 
be reduced somewhat, with an associated 
improvement in spectrum efficiency, at 
the cost of extra discipline in the 
ground stat ion computers and added 
delay. 


One of the uplink channels is designated 
as the "calling channel", on_ which 
stations transmit their initial requests 
for service to the satellite. This 1s 
in contrast tot h e last scheme, in which 
a new Station may request service at any 
time on any channel. Requests would 
indicate the amount of service desired, 


and because tney would be short, traffic 
on the calling channel would hopefully 
be well below the 18% "total bedlam” 
figure. The satellite responds by 
granting the requesting station 
permission totransmitits trafficona 
specific frequency during a given time 


"slot". Depending onthe length of the 
time slots andthe tightness of their 
scheduling, each station might to 


compute and compensate for propagation 
delays which change continuously during 
a pass. 

There are two advantages of Reservation 
Aloha: 


New stations requesting service 
would not interfere with data 
exchanges already in progress on 
the working channels. 


1. 


2. Due to the tight scheduling of the 
working channels, fewer of them 
might be necessary, reducing 


spacecraft hardware complexity. 


4.3 Discussion: Pure Aloha vs. 


Reservation 
These two schemes represent specific 
points in what is actually a fairly 
continuous spectrum of alternatives 
between "total anarchy" and "total 
discipline”. The “more disciplined” 
reservation scheme with the designated 


calling channel can potentially provide 
better channel utilization than the pure 
Aloha method; however,i t suffers from 
an "Achilles Heel" in that it is much 
more susceptible to jamming, accidental 

or otherwise, particularly on the 
calling channel. With any channel 

usable both for calling and working, the 


multi-channel Aloha system provides 
built-in redundancy against certain 
hardware failures a S well agmming. 


For this reason, along with the strongly 
attractive feature of simplicity, we 
feel that each channel should be 
equivalent, although by ground software 
convention one channel could be used 
primarily for initial service requests. 


While the throughput of Aloha may seem 
low, the 18% figure is valid only for a 
very | a r ge. number of users; "excess 
capacity” existSinsystems witha small 
number of users, especially those in 
which one user 
traffic load. If it turns out that 
uplink loading becomes a limiting factor 
(unlikely or reasons discussed 
earlier), it would be possible to change 
operations to a “slotted Aloha" access 
method. This would involve programming 
the ground station computers to "agree" 
that a reference event, e.g, the 
beginning of a certain telemetry frame 
periodically interspersed into the 
downlink data stream, represents. the 
beginning of a packet slot. f the 
ground stations were to time their 


transmissions to coincide with such 


presents most of the 
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slots, the utilization of each channel 
could double to 37%; and this 
improvement could be obtained with no 
changes to spacecraft hardware or 
software. However ,each station would 
have to compute and correct for the 
varying propagat ion delays to the 
satellite aS in the Reservation Aloha 
system. 


5. Summary 


This paper has presented and discussed 
the various modulation and access method 
alternatives available to the PACSAT 
design team. It must be emphasized that 


the conc lus it ons reached here are 
preliminary; only after considerable 
simulation, exper imen ta t ion, and 
breadboarding activity will the final 


decisions be made. 


In any case, it is probably true that we 
have already “over-engi neered" the 
PACSAT uplink in that the downlink will 
almost certainly become the throughput- 
limiting factor. Now if we only had a 
few more watts of power.... 
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Abstract 


This paper describes a system of hardware and 
software which provides for the transfer of blocks 
of data between a VADCG Terminal Node Controller 
(TNC) and a CP/M system with a serial interface. 
Both the software to run in the TNC and in the CP/M 
system is included. The system provides’ block 
transfers, data transparency, flow control and error 
checking and retransmission in both directions over 
the interface. 


Introduction 


The software to implement the Link level of 
protocol for the VADCG Terminal Node Controller was 
developed in 1978. It is now in general use both in 
the J.Se and Canada and has even been implemented on 
other Terminal Node Controller boards. It has 
proven to be satisfactory for the purposes intended 
but many people recognize the need to implement the 
next higher level of protocol #= the Packet or 
Network level protocol. 


There have been a large number of proposals as 
to the form this protocol should take and I have 
made my own proposals in a paper published in the 
last Amateur Radio Computer Networking Conference. 
In spite of a large supply of proposals there is a 
distinct shortage of implementations. Part of the 
reason for this has been because of the need for 
some kind of consensus in the Amateur Radio 
fraternity. Notwithstanding this important concern, 
there is another reason why we don't have our 
Network level protocol implemented = it is a lot of 
work to get it going. 


‘What are the problems in implementing the 
Network level protocol?', you may ask. Well, unlike 
the Link level protocol which only had to be 
implemented to run in a TNC, parts of the Network 
level protocol have to be implemented to run in each 
microcomputer connected to the network. 
Furthermore, the TIP programs in the TNCs will have 
to be rewritten and some changes in the LIP programs 
are needed as wall. In addition, the Network level 
protocol is much more complex than the link level 
protocol. TI think one of the main stunbling blocks 
is the need to implement the protocol on two 
separate systems before any testing can be done. 


Despite the above difficulties, I have begun 
the process of implementing the protocol and have 
broken the job down into steps that can be 
implemented and tested and then proceed to the next 
step. To alleviate the problem of having to make 
two implementations for different systems, T am only 
making one implementation for my ©?/M system which I 
will hopefully be able to transport to another local 
Packeteer's CP/M system for testing In order to 
make this progran as transportable as possidle to 
other CP/M systems TI am only using the _ 8:080 
instruction set. 


The programs here are not really any nart nf a 
higher level protocol but the function they pnerforn 
will »2@ needed by any higher level protocol that is 
adopted. The microcomputer program called 'PACKET' 
is basically a set of drivers for the _ serial 
interface between the microconputer and the TN. 
The program implementing the higher level of 
protocol in the microcomputer is called the 
Transmission Control Program or TCP. The TCP will 
use these drivers to transfer blocks of data that it 
has prepared to the INC and it will also receive 
blocks of data from the TNC using these drivers. 


The TCP is called upon by the programs running 
in the microcomputer to send data and receive data 
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to and from various points in the network. In order 
to do this job, the TCP adds a header onto the 
outgoing blocks of data and because the bits and 
bytes in this header have a meaning based on their 
position in the block of data, there must be a 
mechanism to show where a block starts and ends in 
the serial data streams being passed accross the 
interface between the computer and the TNC. This 
mechanism, was lacking in all the TIPs that I had 
access to. Also, since flexibility in the setting 
of these bits was needed and any 'kind of restriction 
on the data being sent across the interface was 
undesirable, there had to be a mechanism for data 
transparency. This mechanism, too, was missing in 
all the TIPs that I had access to. Also, since data 
was being sent both ways at high speed by 
there had to be a mechanism for 


microprocessors, 
flow control in both directions across’ the 
interface. Also, Since my serial interface used 


long RS -232 cables in a noisy environment, Tf 
occasionally got bit errors in the data especially 
at the higher speeds so I needed to have error 
detection in this interface. In some environments, 
error detection may not be necessary but I decided 
to play it safe and include it. Finally, error 
detection is not of much use unless you can correct 
the errors so I have incorporated a retransmission 
mechanism. 

provides the 


TO summarize = the interface 


following: 


1. BLock recognition. 

2. Data transparency. 

3. Flow control (in both directions) 
4. Error detection. 

DY. EPPoOr Corrections 

A 


block has the following format: 


Oe ee hee ee en ee ee ee ee ee ee) 


! SYN ! DLE ! STX ! DATA ! DLE ! ETX ! CRC ! PAD ! 


1! 16H ! 10H ! 02H ! ! 10H ! O38 ! Y EPH 4A 


a ee eS ff 


The combination DLE-STX (ASCII Data Link Escape 
and Start of Text) indicates the start of a 
transparent block of data and the vsombination DLE- 
ETX indicates the end of the transparent block. To 
provide for data transparency a _ ‘'byte  stuffing' 
technique is used = any time transparent data occurs 
that looks like a DLE, then an extra DLE is stuffed 
into the data stream. Therefore, the two byte 
combination DLE-NDLE represents only a single data 
byte of 10H. 


Flow control is accomplished using some 
hardware features of the TWC and the serial 
inter face on the nicrocomputer. The RTS (Request to 
Send) and CTS (Clear to Send) lines are cross 
connected and controlled by the programs. "When the 
output line is high it means ‘You can send data to 
me now'. When the output line is low it means 
Non't send any data to me now.' 


Error detection is accomplished using the two- 
byte CRC (Cyclic Redundancy Check) characters 
following the FTX character in the block. T am 
using the following polynomial to generate the CRC 
bytes: 


15 


+ X + x2 


x 16 + 1 

This is the usual polynomial used for 
synchronous protocols such as IBM BISYNC but is _ not 
the one suggested by the CCITT. Om transmit, the 
cRC calculation is done on all transmitted 
characters after the STX and up to and including the 
ETX charactec. The stuffed bytes are included in 


the calculation and after the STX is processed, two 
bytes of zeroes are processed. On receive, the 
calculation is the same except that the two CRC 
bytes are used instead of the zero bytes and the 
result of the CRC calculation will then come out to 
zero if everything was received correctly. 


The error correction mechanism employed also 
utilizes some of the hardware features of the TNC 


and the microcomputer. The DTR (Data Terminal 
Ready) and the DSR (DataSet Ready) lines are cross 
connected between the TNC and microcomputer. 
Whenever one side receives a block correctly, it 
reverses the state of its output line. If the other 
side does not detect the transition then, after a 
timeout, it retransmits the block. 
Hardware Requirements 

In order to use the program called 'TIPTTC' 


which runs in the VADCG TNC, you will need a VADCG 
TNC with the serial interface installed and an RS232 
cable with wires going to the following pins 
installed (2,3,4,5,6,7 and 20). 


In order to use the program called _ 'PACKET' 
which runs in a CP/M system, you will need to have a 
serial interface capable of handling 8-bit 
characters, direct software control of two lines of 
RS-232 levels, and the ability to read two input RS- 
232 lines with the software. Most CP/M systems have 
this capability. It is true that I could have 
written this software to only require the data lines 
(and I may yet do this) and the software would be 
slightly more transportable but more complicated and 


a little less efficient. The flow control and 
acknowledgment systems work very well because the 
software in the TNC is alerted by the interrupt 


system almost instantly when there is any change in 
level of the interface lines. 


Software Requirements 


The 'TIPTTC' program should interface with any 
of the common LIP programs being used with the VADCG 
board. I can only think of one thing to watch out 
for = the program uses variables in the CCA (Common 
Communications Area) from displacement 40H to 54H so 
you should check your LIP's usage of these areas and 
relocate them if your LIP uses part of the same 
area. Also, make sure your stack does not get 
extended down as low as displacement 54H in the CCA. 
This “is a wanilvea!. TIP and. in addition: tor -the 
features described above, it only has provision for 
connect and disconnect. If you use this TIP you 
will have to do without those special functions you 
previously had. The other alternative is to add the 
functions to this program yourself. If you take 
this latter option I would very much like to hear 
from you as well as anyone else who uses these 
programs. I like to get 'feedback.' 


The 'PACKET' program only needs a CP/M system 
with the aforementioned hardware features and some 
configuration modifications described in the next 
section. 


Confiauration Requirements 


A. TIPTIIC 


A.1 At label 'BAUDRAT' the Baud rate may have 
to be changed. I am using 4800 Baud. In general it 
is best to have the rate as high as is reliable and 
convenient and should be 1200 or greater. However, 
lower Baud rates than 1200 would work as well. 


A.2 At label ‘ACKTO' there is a number which is 
related to the amount of time the TNC waits before 
retransmitting the block if no acknowledgment is 
received. This value has not been optimized from 
the first trial value. It is very non-critical and 
the value I chose for my system seems to work very 
well. It is probably quite a bit slower than 
required. You may experiment with different values. 


A.3 At label 'RIMBUF' change the call sign to 
your own and if it is less than 6 characters, pad it 
on the right with blanks. Also, use upper case 
characters. 


A.4 At label 'TERMNO! 
to whatever you want. 


change your node number 


B. PACKET 
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Bel In the section headed 'HARDWARE PORT 
EQUATES' you will have to change the port addresses 
to match the ports on your system. 

Bye In the sections headed 'CONTROL PORT BIT 
MEANINGS' and 'STATUS BIT MEANINGS' you will have to 
change the equates to match your system. 

B.3 At label ‘"UARTINIT" change the code to 
initialize your serial interface UART to operate 
with 8 data bits and no parity bit. Also make the 
output lines going to pins 4 and 20 on the TNC are 
low. (The assumption here is that the jumper plug on 
the TNC is wired straight across) 

B.4 At label 'SETRTS' change the code so that 
it makes pin 4 on the TNC end of the cable high. 

B.5 At label 'CLEARRTS' change the code so that 
it makes pin 4 on the TNC end of the cable low. 

B.6 At label 'FLIPDTR' make sure the 
reverses the level on pin 20 of the TNC. 

Be7 At label 'TESTTBE' test if data can be sent 
out to the UART and return non-zero status if it 
Gani, 


code 


Bw: At babel. “IESTRDA* -test -i1f data iss 
available from the UART and return non-zero status 
ti Te, Sy 

B.9 At label 'TESTCTS' test the level of pin 5 
coming from the TNC and return non-zero status if it 
is high. 

B.10 At label 'TESTDSR' 
coming from the TNC and compare 
tested level. If the value has changed, 
zero status. 

Be11 In routine 'KEYTEST' change the code to 
Look for a character to be entered on your keyboard 
and if there is none, then go to 'OUTTEST’. It will 
probably have to be changed because my keyboard uses 
inverted logic. 


test the level of pin 6 
it to the last 
return non- 


Operation 


Although the importance of the "PACKET' program 
lies in the features provided by the drivers in it, 
I have added 25 instructions which allow the program 
to provide an immediately useful function. Tt will 
allow the user to use the keyboard and screen 
display in the CP/M system as if it were a terminal 
connected directly to the TNC. Because of the power 
of the driver code, it is a relatively trivial 
matter to add this function. Similarrily, a program 
to transfer a file from the system or to the system 
is very easy to implement using the drivers. 


To use the program as a terminal simulator, 
simply type ina line of data on the keyboard, the 
line will be sent in a block to the TNC when the 
line feed key is pressed. While data is being 
entered after the first character, no blocks will be 
received from the TNC. While a block is being 
received from the TNC, the keyboard is not tested so 
a line that you enter will not be mixed with data 
coming from the TNC. 


To connect, type the Call sign in upper case 
(which must be padded with blanks on the right if it 
is not 6 characters long) followed by control-A and 
then hit line feed to send it to the TNC. To 
disconnect, type any 6 characters (except for line 
feed) followed by control-B and then hit line feed. 
Sorry for this kludge but it is only temporary as I 
am planning to completely change the connect- 
disconnect procedures when I write the Transmission 


Control Program which is the next step in 
implementation of the Packet level protocols. 
Summary 

I hope these programs help those who are 
working on the implementation of the higher level 
protocols for an Amateur Radio digital 
communications network. It seemed to me that a 


program with these features would have to be one of 
the first steps in any kind of implementation but so 
far I have not heard of one. Perhaps someone out 
there has already written one and I have duplicated 
hrs ettort. If so, then we are not doing enough 
advertising about what we have done. That is why I 
have taken this effort to disseminate the program. 


The program listings here represent programs 
that have actually been running successfully soany 
problems encountered in transporting them to another 
system should be associated with the diffferent 
environment and not with defects in the code. I can 
supply the programs on standard SS-SD CP/M format 
diskettes if necessary. Please enclose $3.00 with a 
blank diskette or $8.00 without a diskette when 
making your request. You will find the listings for 
the two programs on the following pages. 

* CP/M is a trade mark of Digital Research 
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0100 31¢903 
0103 CD4301 
0106 CD3501 
0109 CA2301 
910C DBNO 
Q10E E602 
0110 c20601 
0113 DBN2 
0115 CD3A01 
0118 CD3A05 
011B FEOA 
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* THIS PROGRAM CONTAINS THE DRIVERS TO EXCHANGE TRANS- *# 
PARENT BLOCKS OF DATA BETWEEN A CP/M OPERATING 


SYSTEM AND A VADCG TERMINAL NODE CONTROLLER USING A 
MATCHING 


PROGRAM. 


IT USES THE REQUEST TO SEND (RTS) 


AND CLEAR TO SEND (CTS) LINES FOR FLOW CONTROL AND 
THE DATA SET READY (DSR) AND DATA TERMINAL READY 


(DTR) LINES FOR ACKNOWLEDGEMENTS. 


USES 


"BYTE STUFFING' 
AND USES A CRC-16 TO DETECT ERRORS. 


ONLY DATA INFOR- 


TO ACHIEVE DATA TRANSPARENCY 


IF THE TRANS= 


MITTED DATA IS NOT ACKNOWLEDGED BY A CHANGE IN LEVEL 


THEN THE BLOCK IS SENT AGAIN 
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PRERERERERRERERARERRERAEERERAERHEERERREREEERERAEERE EERE 
MISCELLANEOUS EQUATES 


Los 
} 

} 

CR 
LF 
DLE 
STX 
ETX 
SYN 
PAD 


EQU 


ASCII EQUATES 


ODH } 
OAH 3 
10H ? 
02H 3 
03H ? 
16H 3 
OFFH 


CARRIAGE RETURN 

LINE FEED 

DATA LINK ESCAPE 

START OF TEXT 

END OF TEXT 
SYNCHRONIZING CHARACTER 


# PAD CHARACTER 


E 
ED i aaa e CaCO OK EEEA ALES Ais aRRa OSA TEI NaL ORS 


BIT MEANING 


3 UART DATA PORT 

; UART CONTROL PORT 
$ UART STATUS PORT 

1 KEYBOARD DATA PORT 


s 

} NOT DATA TERMINAL READY 
} NOT REQUEST TO SEND 

3; BAUD RATE SELECT 

} BAUD RATE SELECT 

} WORD LENGTH SELECT 

+ WORD LENGTH SELECT 

} STOP BIT SELECT 

; PARITY INHIBIT 


RECEIVE DATA AVAILABLE 
NOT KEYBOARD STROBE 
PARITY ERROR 

FRAMING ERROR 

OVERRUN ERROR 

NOT DATA SET READY 

NOT CLEAR TO SEND 
TRANSMIT BUFFER EMPTY 


ee BH HE SE e- GS OR 


RARLEREARARERERERAARAAARAARERAREERAHTERTRHARAAKRERARAKRHRAARERERD 


) INITIALIZE STACK 

+ INITIALIZE UART 

3 ANY DATA IN TBUF? 

7 NO, TRY TO RECEIVE SOME 
3 ANY KEYBOARD DATA? 


NO, TEST FOR LINE DATA 
GET DATA 

DISPLAY IT 

PUT IT INTO BUFFER 
WAS IT A LINE FEED? 


; HARDWARE PORT EQUATES 

DATA EQU 01H 

CONTROL FQU OOH 

STATUS EQU OOH 

KEY BD  EQU 02H 

; CONTROL PORT 

DTR EQU 01H 

RTS EQU 02H 

BRSO EQU 04H 

BRS1 EQU OSH 

WLS 1 EQU 10H 

WLS2 EQU 20H 

SBS EQU 40H 

PI EQU 80H 

3 

} STATUS BIT MEANING 

RDA EQU 018 

KSTB EQU 02H 

PE FOU 04H 

FE EQU 08H 

OE EQU 10H 

DSR EQU 20H 

CTS EQU 40H 

TBE EQU 80H 
ORG 100H 
LXX SP, STACK 
CALL UAPTINIT 

OUTTEST : CALL WRITESTAT 
SZ LINETES 

KEYTEST: IN STATUS 
AN1 KSTB 
INZ OUTTEST 
IN KEYBD 
CALL DISPLAY 
CALL WRITE 
CPI LF 
cz TCLOSE 


=e ae @ SS GD BS 


YES,SEND DATA IN BUFFER 


0120 c30601 


0123 CD3505 
0126 CC3A04 
0129 CAOCO1 
012C CD1805 
012F CD3A01 
0132 €C32301 


0135 3A9B02 
0138 Bp? 
0139 C9 


O13A FS 
013B SF 
013C OE02 
013E CD0500 
0141 FI 
0142 ¢c9 


3EB? 
0145 D300 
329801 
014A DBO1 
014C DBOO 
014E E620 
0150 329701 
0153 c9 


54 39801 
57 E6FD 
59 D300 
5B 329801 
SE C9 


O15F 3A9801 
0162 F602 
0164 8300 
329801 
0169 C9 


O16A 3A9801 
016D EE0O1 
016F D300 
329801 
0174 C9 


5 DBOO 
E680 


017A DBOO 
017C E601 
O17E C9 


017F DBOO 
0181 £64) 
0183 FE40 
0185 c9 


JMP OUTTEST 9 GO POR MORE DATA 
LINETEST: 
CALL READSTAT + DATA IW RECEIVE BUFFER? 
CZ BLOCKRX + NO, TRY TO RECEIVE SOME 
JZ KEYTEST 3 NO, TEST KEYBOARD ENTRY 
CALL READ 3 GET DATA BYTE FROM RBUF 
CALL DISPLAY 3 AND DISPLAY IT 
JMP LINETEST 
WRITESTAT: 
LDA TBUFNUM 3 GET COUNT 
ORA A 3 AND TEST IT 
RET 
DISPLAY: PUSH PSW 
MOV E,A 
MVI C,2 
CALL BIOS 3 DISPLAY DATA IN (€) 
POP PSW 
RET + RETURN TO CALLER 
REAEARRARAKRARHAARHRRAKKRERTARAERKRRARKAKHREAERLATHRAEARERRERARRAAEER 
? BASIC UART DRIVER ROUTINES 
} 
} INITIALZATION OF UART 
UARTINIT: 
MVI A, PI+WLS 14+WLS 2+BRS0+DTR+RTS 3 8 DATA, 
OUT CONTROL }; NO PARITY, DTR AND RTS OFF: 
STA CTRL } SAVE CONTROL INFO 
IN DATA 3 CLEAR ANY RESIDUAL DATA 
IN STATUS ? SAVE INITIAL DSR STATUS 
ANI DSR 
STA DSRSTAT 
RET 


» RETURN TO CALLER 


ENABLE RTS (MEANS DATA CAN BE RECEIVED) 


; 
SETRTS: LDA 


CTRL 3 GET CONTROL INFORMATION 
AN1 OFFH-RTS 
OUT CONTROL 
STA CTRL 
RET 
} DISABLE RTS ( MEANS DO NOT SEND ME ANY DATA ) 
CLEARRTS: 
LDA CTRL 3 GET CONTROL INFORMATION 
ORI RTS 
OUT CONTROL 
STA CTRL 
RET 
} REVERSE VALUE OF DIR (TO ACKNOWLEDGE BLOCK ) 
FLIPDTR: LDA CTRL » GET CONTROL INFORMATION 
XRI DTR } FLIP OTR 
OUT CONTROL 
STA CTRL 3 SAVE UART CONTROL INFORMATION 
RET } RETURN TO CALLER 
) TEST VALUE OF TBE (TRANSMIT BUFFER EMPTY) 
TESTTBE: IN STATUS 
ANI TBE 
RET 
} TEST IF RECIEVE DATAIS AVAILABLE 
TESTRDA: IN STATUS 
ANI RDA 
RET 
? TEST VALUE OF CLEAR TO SEND 
; NON-ZERO FLAG IF CTS, ZERO FLAG IF NO CTS 
TESTCTS: IN STATUS 
AN1 cTs 
CPI cTs NOTE SENSE INVERTED 
RET 


ofS 


0186 
0187 
0188 
018B 
018C 
018E 
0190 
0191 
0192 
0193 
0194 


0195 
0197 
0198 
OOFA 
0199 
0198 
019C 
0299 
0298 
029C 
0392 
03c9 


03C9 
03CC 
Q3CD 
03CE 
O3CF 
03D2 
03D3 
03D4 


NxAWe 


USVI 
03D8 
O3DB 
O3DE 
0351 
03E4 
03E5 
0357 
03E8 
03E9 


O3EA 
03EB 

03EC 
USEF 


03F0 
O3F1 
03F2 
O3F5 
03F7 
O3FA 


O3FB 
Q3FF 


wwe 


O3FF 
0400 


CD5205 
E5 

Gia) 

4F 
210100 
ZB 

ie 

B5 


PaAnAN 
C2026 


CD7501 
CAD803 
CD7F01 
CADE03 


TE 
CDC903 
FE10 
CCCg03 


0401 3E16 


TEST IF VALUE OF DATA SET READY HAS CHANGED 
NON-ZERO FLAG IF DSR HAS CHANGED, ZERO IF NOT 


me *O 


TESTDSR: PUSH H : DO NOT CHANGE HL 

PUSH B + OR BC 

LX1 H, DSRSTAT 3; POINT AT OLD DSR STATUS 

MOV B,M 

IN STATUS 

AN1 DSR 

MOV M,A ¢ SAVE NEW DSR STATUS 

CMP B s COMPARE OLD AND NEW 

POP B ; RESTORE REGISTERS 

POP H 

RET ¢ RETURN WITH FLAGS SET 
JUSTO ISIS SISOS OTIC ISIS GEI TIGA 
DSRSTAT:DB 0 ¢* DSR STATUS SAVE AREA 
CTRL: DB 0 s CONTROL PORT INFORMATION 
MAXNUM EQU 250 3s MAXIMUM AMOUNT OF DATA ALLOWED 
RPOINT: DW RBUF ¢$ NEXT POINT TO GET DATA IN RBUF 
RBUFNUM: DB 0 3; NUMBER OF BYTES IN RBUF 


RBUF: DS 233 : RECEIVE BUFFER 


TPOINT: DW TBUF : NEXT POINT TO PUT DATA TN TRUF 
TBUFNUM:DB 0 7 NUMBER OF BYTES TN TBUF 
TBUF: DS 253 s TRANSMIT BUFFER 
DS 30H s STACK AREA 
STACK EQU $ 
KKK KKH RE KK IKKE KKK EERE EKER KKK KEK KKEKKKKKKEKKKKEKEKEKSK 
: SEND BYTE OF DATA OUT TO SERIAL PORT 
: DATA PASSED IN ACCUMULATOR 
SENDDATA: 
CALE CALCCRC e INCLUDE IN CRC 
SEND: PUSH H 
PUSH B : SAVE B&C 
SEND1: MOV C,A s SAVE DATA TEMPORARILY 
LX1 Hl ; DELAY FOR BUG IN UART 
SEND2: DCX H 
MOV A,H 
ORA L 7; IS IT o? 
NZ SEND2 
SEND3: CALL TESTTBE : IS TBUF EMPTY? 
JZ SEND3 a “NO KEEP LOOPING UNTIL IT TS. 
SEND4: CALL TESTCTS s IS CLEAR TO SEND UP? 
JZ SEND4 «NO; CAN'T SEND: YET 
MOV A,C : GET BACK DATA BYTE 
OUT DATA 
POP B 3 RESTORE B 
POP H 
RET : RETURN TO CALLER 
: SEND DATA IN TBUF TO THE UART TRANSPARENTLY 
SENDTBUF: 
PUSH H 
PUSH B 
ify a H, TBUFNUM : POINT TO TBUF BYTE CNT 
MOV C,M : SAVE IN C 
SENDTBUF 1: 
INX H : POINT TO NEXT BYTE 
MOV A, M ; GET IT 
CALL SENDDATA : SEND IT 
CPI DLE : WAS IT DLE? 
ew SENDDATA : IF SO, SEND IT AGAIN 
NCR C : DECREMENT COUNT 
JINZ SENDTBUF? 3 CONTINUE SENDING 
POP B 
POP H 
RET : RETURN TO CALLER 


SEND FORMATTED BLOCK TO UART 
BLOCKTX: 


MVI A, SYN 


0403 
0406 
0408 
040B 
040D 
0410 
0413 
0416 
0419 
041B 
O41E 
0420 
0423 
0426 
§429 
042C 
042F 
0430 
0433 
0436 
0439 


043A 


043D 
0440 
0441 
0443 
0446 
0449 
044A 
044C 


044F 
0452 
0455 


0458 
NASA 


wide 


045B 
Q45E 
0461 
0462 
0465 
0466 
0469 
046C 
046D 
0465 
0471 
0474 
0475 


0478 
O47A 
047B 


O4A7C 
047E 
O47F 


0480 
0483 
0486 
0489 


0488 
048E 


CDCCO3 
3E10 
CDCC03 
3E02 
CDCC03 
210000 
229501 
CDEA03 
3E10 
CDC3903 
3E03 
CcDC303 
CDDE04 
CDF204 
cnnad4 
CA0104 
AF 
329B02 
219C02 
229902 
C9 


CD5401 


21ICOI 
229901 
CD8004 


C8 
PEN 


eet 


C23D04 
CDAE04 


210000 
229501 
219C01 
OEOO 


CDAE04 
C8 


BLOCKRX: 


BLOCKRX1: 


SEND 

A,DLE 

SEND 

A, STX 

SEND 

H,0 ¢s INITIALIZE CRC AREA 
CRC 

SENDTBUF s SEND DATA IN TBUF 

A, DLE : THEN DLE-ETC SEKQUENCE 
SENDDATA s INCLUDE IN CRC 

A,ETX 

SENDDATA ¢ INCLUDE IN CRC 

SENDCRC s FINALLY SEND CRC BYTES 
CHECKRX s TRY TO RECEIVE 

WALTDSR 7 WALT FOR DSR TO CHANGE 
BLOCKTX ; DIDN'T CHANGE, SEND BLOCK AGAIN 
A s A <-- 0 

TBUFNUM s INDICATE TBUF IS EMPTY 
H, TBUF * POINT TO START OF TBUF 
TPOINT 


3; RETURN TO CALLER 


READ A FORMATTED TRANSPARENT BLOCK OF DATA 


CALL 


CALL 
RZ 
CPI 
JNZ 
CALL 
RZ 
CPL 
JNZ 


BLOCKRX2: 


BLOCKRX3: 


; 
RCVRBUF 


LX1 
SHLD 
CALL 


RZ 
CPt 
JNZ 
CALL 
RZ 
CALL 
RZ 
CALL 
LHLD 
MOV 
ORA 
JNZ 
LX1 
MOV 
CALL 


MVI 
ORA 
RET 


MYT 
ORA 
RET 


RECEIVE 
CONTROL 


:LXI 


SHLD 
LXI 


SETRTS ; ALLOW OTHER END TO SEND 


RECEIVE 3; READ A BYTE FROM LINE 
s RETURN WITH ZERO STATUS IF TIMED OUT 


DLE : CS: IT DLE? 
BLOCKRX1 * NO, KEEP TRYING 
RECEIVE ; GOT DLE, TRY FOR STX 


; RETURN WITH ZERO STATUS IF TIMED OUT 


Sry , 1S IT STx? 

BLOCKRX 1 + NO, TRY FOR DLE AGAIN 
: ENTRY FROM BLOCKTX 

H, RBUF : POINT TO START OF RBUF 

RPOINT 

RCVRBUF ; RECEIVE DATA INTO RBUF 


; UNTIL A CONTROL SEQUENCE IS RECEIVED 
; RETURN ZERO STATUS IF LINE TIMES OUT 


ETN * WAS I” FTX? 

BLOCKRX1 : UNEXPECTED SEQUENCE 

RECEIVE * RECEIVE (FIRST CRC-CHAR 
; RETURN HERE IF TIME OUT 

RECEIVE ; RECEIVE SECOND CRC CHAR 
- RETORN ERE: LF EiME OUT 

CLEARRTS -(o.LOP. OT HER END 

CRC ; CHECK IF CRC WAS OK 

A,H 

L 

BLOCKRX3 ; NO GOOD 

H, RBUFNUM 3; SAVE DATA COUNT 

M,C 

FLIPDIR ; GOOD, REVERSE DTR LINE 
7 TO ACKNOWLEDGE BLOCK 

A,-1 ; RETURN NON-ZERO STATUS 

A ; BLOCK RECEIVED OK 
; RETURN TO CALLER 

A, ¢ RETURN. WITH ZERO: STATUS 

A + NO BLOCK RECEIVED 


DATA PORTION OF BLOCK, RETTJRNS WHEN A 
SEQUENCE FOUND IN THE TRANSPARENT TEXT 
H, 0 ; INITIALIZE CRC TO 0 
CRC 

H, RBUF > POINT TO START OF RBUF 
C20 » BYTE COUNT = 0 

RECEIVE * GET A BYTE FROM LINE 


3; RETURN HERE WITH ZERO STATUS IF TIMEOUT 


O4F2 


FP FE10 


CA9A04 


77 
23 


oc 
C38B04 
CDAE04 


ES 
CD5401 
2 AOOF 


C3B504 


ES 
cp5401 
210007 


B 
C2BS504 
CD5F01 


3E00 
B7 


E1 
c9 


011027 


3A9B01 


CPL DLE 3 WAS IT DLE? 
JZ RCVRBUF3 ? YES, LOOK AT NEXT BYTE 
RCVRBUF 2: 
MOV M,A ? PUT INTO BUFFER 
INX H 3 INCREMENT RBUF POINTER 
INR c 3 INCREMENT count 
P RCVRBUF 1 3 LOOP FOR NEXT BYTE 
RCVRBUF3: 
CALL RECEIVE 
RZ 3 ZERO STATUS RETURN IFLINE TIMES OUT 
CPI DLE 3 IS IT A TRANSPARENT DLE? 
JZ RCVRBUF2 : YES, GO PUT INTO BUFFER 
RET 3 RETURN WITH CONTROL BYTE IN ACCUMULATOR 
? AND NON-ZERO STATUS 
; TRY TO READ PROM LINE WITH LONG TIMEOUT 
RECEIVL: PUSH H 
CALL SETRTS 3 ALLOW OTHER END TO SEND 
LXI H,4000 LONG TIMEOUT VALUE 
} SHOULD BE ADJUSTED FOR BEST RESULTS 
JMP RECEIV1 
: TRY TO READ FROM LINE, IF LINE TIMES OUT, 
? RETURN WITH ZERO STATUS 
RECEIVE: PUSH H 
CALL SETRTS + ALLOW OTHER END TO SEND 
LX1 H, 2000 ? SHORT TIMEOUT VALUE, 
? ADJUST FOR ABOUT 2 CHAR TIMES 
RECEIV1:CALL TESTRDA 3 ANY RECEIVED DATA? 
IZ RECEIV2 3 NO, DECREMENT TIME 
IN DATA 3 GET DATA BYTE 
CALL CALCCRC 3 INCLUDE IT IN CRC 
POP H 
RET 3 GOOD RETURN WITH NON ZERO STATUS 
RECEIV2: DCX H 3 DECREMENT TIMER 
MOV A,H 
ORA L } IS TIME OVER 
INZ RECEIV1 3 NO, KEEP TRYING 
CALL CLEARRTS 3 OOPS, TIMED OUT, 
: DROP RTS SO OTHER SIDE WILL STOP 
MVI A,0 3 RETURN WITH ZERO STATUS 
ORA A 
POP H 
RET 
; WAIT FOR DSR TO CHANGE USING TIMEOUT 
WAITDSR: 
LXI B, 10000 : DELAY © ALTER AS REQ'D 
WAITDSR?: 
CALL TESTDSR } CHECK FOR DSR CHANGE 
RNZ } RETURN IF IT HAS 
DCX B 
MOV A,B 
ORA Cc 3 IS TIME OVER? 
JNZ WAITDSR1 3 NO CONTINUE TESTING 
RET } UNSUCCESSFUL RETURN 
? SENDTHECRC BYTES 
SENDCRC : XRA 3} FINISH CRC CALCULATION 
CALL CALCCRC 
CALL CALCCRC 
LDA CRC+1 3} SEND FIRST CRC CHAR 
CALL SEND 
LDA CRC } SEND SECOND CRC CHAR 
CALL SEND 
REX 
3 CHECK IF WE CAN RECEIVE A BLOCK NOW 
3 THIS ROUTINE IS CALLED AFTER A BLOCK HAS BEEN 
’ TRANSMITTED TOALLOW THE OTHER SIDE TO GET A 
? CHANCE TO SEND TO US 
CHECKRX: LDA RBUFNUM 3 IS THERE ANY DATA LEFT 


04F5 
O4F6 
04F7 


O4FA 
04FD 
04FE 
0500 
0503 
0506 
0507 
0509 


050C 
O50F 


0554 
0555 
0557 

0558 
055B 
055B 


B? 
co 
CD5401 


CDA404 
C8 
FE10 
C2FA04 

CDA404 
C8 
FEO2 
C2FA04 
CD4F04 
cg 


3A9B02 
B7 
c40104 
C9 


ES 
219B01 
7E 


B7 

C22A05 
CD1005 
CD3A04 
c31905 


35 

2A9901 
7E 

23 
229901 
EI 


cg 


3A9B01 
B7 
c9 


F5 
0608 


4F 
2A9501 


79 


ORA 
RNZ 
CALL 


CHECKRX1: 


’ 
} 
TCLOSE: 


READ: 
READ 1: 


READ2: 


WRITE: 


LDA 
.@) 


A 
SETRTS 


RECEIVL 


DLE 
CHECKRX 1 
RECEIVL 


STX 
CHECKRX 1 
BLOCKRX2 


=e ee We Ww 


ws GS SS SS TS TO W BE % BE 


IN RECEIVE BUFFER? 
YES, CAN'T RECEIVE 
ENABLE RTS TO ALLOW 
OTHER SIDE TO SEND 


READ WITH LONG TIMEOUT 
TIMED OUT , RETURN 

IS IT A DLE? 

NO, KEEP LOOKING 

NOW LOOK FOR A STX 
TIMED OUT SO RETURN 

IS IT START OF TEXT? 
NO, KEEP LOOKING 

NOW GO READ TRANSP. TEXT 
ZERO STATUS IF TIMEOUT 


} NON-ZERO IF BLOCK WAS RECEIVED 


SEND A BLOCK OF TRANSMIT DATA TO THE LINE I? 
THERE IS ANY DATA IN THE BUFFER 


GET COUNT IN BUPPER 


} TEST FOR DATA 
» SEND BLOCK IF ANY DATA 


= 


se ee Te TE GE BS TO WS SS US RO 


RETURN TO CALLER 


SAVE HL 
POINT AT COUNT IN RBUP 


IS THERE M LEFT? 
YES 

SEND ANY DATA IW TBUP 
RECEIVE ANOTHER BLOCK 
TRY TO DO READ AGAIN 
DECREMENT COUNT 

GET READ POINTER 

GET DATA BYTE 
INCREMENT POINTER 

AND SAVE AGAIN 
RESTORE HL 


? RETURN TO CALLER WITH DATA IN A 


RBUFNUM 3 GET COUNT OF DATA IN BUFFER 
A TEST I 


3 NON-ZERO STATUS IF DATA PRESENT 


3 CRC CALCULATION ROUTINE 


+ USES BYTE PASSED 


ee te tO 8 


SAVE DATA 

SAVE HL 

GET POINTER INTO TBUF 
PUT DATA INTO BUFFER 
INCREMENT POINTER 


POINT To COUNT IN TBUF 
INCREMENT COUNT 


IS BUFFER PULL? 


YES, SEND BLOCK NOW 
RESTORE HL 


RESTORE DATA 


IN ACCUMULATOR TO INCLUDE IN CRC 


3? RESTORES ALL REGISTERS AND STATUS 
CALCCRC : PUSH 


PUSH 
PUSH 
MVI 
MOV 
LHLD 


CALCCRC 1: EQU 


MOV 


Lv'c 


05 
C25B05 
229501 
F1 

cl 

El 

cg 


MOV 
CALCCRE2: 
DCR 
JNZ 
SHLD 
POP 
POP 
POP 
RET 


END 


-~ = 


-~ = 


CCRC2 


Pm oe Se GP Ctl 


rormoram rr YO 
=~ On p~ 


~ 


Nee 
por 


B 
CALCCRC1 
CRC 

PSW 

B 

H 


1000 


0008 
0009 
OOOA 
000B 


0004 
0008 
0010 


me me we De TE 


me ue TO TE TO TS TWH TO TO NO TO BO TH WH WE 


LAST CHANGED: 


INCTB MACRO 2D 
NOT NUL ?D 


IF 


MVI A,?D 
ENDIF 

RST 2 
ENDM 


INCLB MACRO ?D 
NOT NUL ?D 


A, 2D 
3 


COMPARE MACRO 


SIM MACRO 


30H 


RIM MACRO 


3; RAM CONSTANT 


LORAM EQU 


¢ NON-ZERO STATUS MEANS LINE BUFFER ADDRESS IS IN HL REG. 
3; ZERO STATUS MEANS NO BUFFER IS READY 


20H 


NEXTIN MACRO 


RST 
ENDM 


4 


- CHANGE 
1000H 


TERMINAL NODE CONTROLLER. 


INTERFACE PROGRAM (LIP) 


VE7APU 


(ee RSERRERSERELERSLARSSLELSSER ELSE LEE LEE SELECT PE ESE PSL SY 


bald VADCG TERMINAL NODE COMMUNICATIONS PROGRAM 
ak BY DOUG LOCKHART, 
HH KKK KI IKK RII KKK RIKI TERE IKI IKARIA EEE ER 


JANUARY 31, 1983 


JANUARY, 1983 


TERMINAL INTERFACE PROGRAM FOR INTERFACING TO A CP/M 
SYSTEM. THIS PROGRAM IS WRITTEN TO RUN IN THE VADCG 
IT INTERFACES WITH A LINK 
RUNNING AT ADDRESS O IN MEMORY. 
THIS VERSION IS WRITTEN TO USE THE 8250 PROGRAMMABLE 
UART TO COMMUNICATE WITH A COMPUTER. 
THE BASIC FEATURES OF THIS TIP ARE: 
TRANSFER OF DATA IN BLOCKS 

RTS FLOW CONTROL FROM DIGITAL EQUIPMENT TO TIP 
AND CTS FLOW CONTROL FROM TIP TO DIGITAL EQUIPMENT 
ACKNOWLEDGEMENTS TO BLOCKS RECEIVED BY A CHANGE IN DTR 
ACKNOWLEDGEMENTS TO BLOCKS SENT BY A CHANGE IN DSR 
CRC-16 CHECKING OF ALL DATA BLOCKS 
ERROR RECOVERY BY RETRANSMISSION IF NO ACKNOWLEDGMENT 
USES BYTE STUFFING TECHNIQUE FOR DATA TRANSPARENCY 


SET INTERRUPT MASK 


READ INTERRUPT MASK 


FOR DIFFERENT RAM LOCATION 
START OF RAM STORAGE 


e 
i 


3 8255 PARALLEL I/O EQUATES 


PORTA EQU 
PORTB  EOQU 
PORTC  EOU 
CONTROL EOU 


; BAUD RATE 
BAUD384 EQU 
BAUD192 EQU 
BAUD96 EQU 


8 
g 
OAH 
OBH 


EQUATES 
4 


8 
16 


me =e ‘ee "8 


=p ™e NE 


PORT A INPUT AND OUTPUT 
PORT B INPUT AND OUTPUT 
PORT C INPUT AND OUTPUT 
CONTROL PORT OUTPUT ONLY 


DIVISUK FOR 
DIVISOR FOR 
DIVISOR FOR 


38,400 BAUD 
19,200 BAUD 
9600 BAUD 


ova 


BAUD48 
BAUD24 
BAUD12 
BAUD 600 
BAUD300 
BAUD150 
BAUD134 
BAUD110 
BAUD75 
BAUD50 


EQU 
EQU 
EOU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


me ™S Se SO GS TSO SSB BSE TSH NO 


; 8250 SERIAL I/O EQUATES 


3; REGISTER EQUATES 


RBR EQU 0 i 
THR EQU 0 : 
IER EOU 1 i 
IIR EQU 2 ; 
LCR EQU 3 
MCR EQU 4 i 
LSR EQU 5 
MSR EQU 6 i 
DLL EQU 0 ; 
DLM EQU 1 
; INTERRUPT ENABLE EQUATE 
ERBFI EQU 1 ; 
ETBEI EOU 2 ; 
ELSI EQU 4 ; 
EDSSI EQU 8 ; 
: INTERRUPT IDENTIFICATION 
IPEND EQU 1 i 
IIDO EQU 2 i 
IID1 EQU 4 i 
s LINE CONTROL EQUATES 
WLSO EQU 1 i 
WLS 1 EQU 2 
STB EQU 4 

PEN EQU 8 i 
EPS EQU 10H i 
SPTY EQU 20H jl 
SBRK EQU 40H i 
DLAB EQU 80H ; 
* MODEM CONTROL EQUATES 
DTR EQU 1 ; 
RTS EQU 2 i 
outTh EOU 4 
OUT2 EQU 8 : 
LOOP EQU 10H 
; LINE STATUS EQUATES 

DR EQU ! i 
OE EQU 2 
PE EQU 4 i 
FE EQU 8 
BI EQU 10H : 
THRE EOQU 20H t 
TSRE EQU 40H ; 
; MODEM STATUS EQUATES 
DCTS EQU l 
DDSR FOU 2 
TERI EQU 4 

DRLSD EQU 8 
CTS EQU 10H i 
DSR EQU 20H 
RI EQU 40H : 


DIVISOR FOR 4800 BAUD 
DIVISOR FOR 2400 BAUD 
DIVISOR FOR 1200 BAUD 
DIVISOR FOR 600 BAUD 
DIVISOR FOR 300 BAUD 
DIVISOR FOR 150 BAUD 
DIVISOR FOR 134.5 BAUD 
DIVISOR FOR 110 BAUD 
DIVISOR FOR 75 BAUD 
DIVISOR FOR 50 BAUD 


RECEIVE BUFFER REGISTER (R) 
TRANSMIT HOLDING REGISTER (W) 
INTERRUPT ENABLE REGISTER (W) 
INTERRUPT IDENT. REGISTER (R) 
LINE CONTROL REGISTER (R/W) 
MODEM CONTROL REGISTER (R/W) 
LINE STATUS REGISTER (R/W) 
MODEM STATUS REGISTER (R/W) 
DRIVER LATCH (LSB) (W) 

DRIVER LATCH (MSB) (W) 


ENABLE RECEIVED DATA INTERRUPT 
ENABLE TRANSMITTER 

RECEIVER LINE STATUS INTERRUPT 
ENABLE MODEM STATUS INTERRUPT 


EQUATES 

‘O' IF INTERRUPT PENDING 
INTERRUPT IDENTIFICATION BIT 0 
INTERRUPT IDENTIFICATION BIT 1 


WORD LENGTH SELECT BIT 0 
WORD LENGTH SELECT BIT 1 
STOP BIT SELECT 

PARITY ENABLE 

EVEN PARITY SELECT 

STICK PARITY 

SET BREAK 

DRIVER LATCH ACCESS BIT 


DATA TERMINAL READY 
REQUEST TO SEND 

OUT1 LINE ON 8250 

OUT2 LINE ON 8250 
MODEM LOOP CONTROL BIT 


DATA READY 

OVERRUN ERROR 

PARITY ERROR 

FRAMING ERROR 

BREAK INTERRUPT 

TRANSMYT TVER "HULDING REG EMPTY 


TRANSMITTER SHIFT REG EMPTY 


DELTA CLEAR TO SEND 

DELTA DATA SET READY 
TRAILING EDGE RING INDICATOR 
DELTA RX LINE SIGNAL DETECT 
CLEAR TO SEND 

DATA SET READY 

RING INDICATE 


0017 


1000 
1004 
1006 
1008 
100A 
100C 
100E 


1012 
1014 
1016 
1018 
101A 


1000 


RLSD EQU 80H ?; RECEIVE LINE SIGNAL DETECT 
RIMD EQU 17H ; REQUEST INITIALIZATION MODE 
MSE EQU 08H ; MASK SET ENABLE BIT 


¢ COMMON COMMUNICATIONS 


AREA 


¢ CIRCULAR TERMINAL BUFFER VARIABLES 


CCA EQU LORAM ¢ COMMON COMMUNICATIONS AREA ADR. 
CTBIE EQU CCA+4 :; CURRENT TERMINAL BUF INP. ENTRY 
OTBE EQU CCA+6 + OLDEST TERMINAL BUFFER ENTRY 
TBIP EQU CCAt+8 3; TERMINAL BUFFER INPUT POINTER 
TBOP EQU CCA+OAH ; TERMINAL BUFFER OUTPUT POINTER 
LTBOE EQU CCA+OCH 7 LAST TERMINAL BUF OUTPUT ENTRY 
CTBOE EQU CCA+OEH 3; CURRENT TERMINAL BUF OUT ENTRY 


3 CIRCULAR LINE 


LBPE EQU CCA+12H ; LINE BUFFER PROCESSING ENTRY 
CLBE EQU CCA+14H 3; CURRENT LINE BUFFER ENTRY ADDR. 
OLBE EQU CCA+16H ; OLDEST LINE BUFFER ENTRY 

LBIP EQU CCA+18H ; LINE BUFFER INPUT POINTER 

LBOP EQU CCA+1AH ; LINE BUFFER OUTPUT POINTER 

: MISCELLANEOUS 

STATI EQU CCA ¢ MAINLINE STATUS BYTE 

: THE FOLLOWING VARIABLES ARE FOR EXCLUSIVE USE BY TIP 
BUFCOUNT EQU CCA+1CH ; CURRENT INPUT BUFFER COUNT 
OUTCOUNT EQU CCA+1DH ; CURRENT OUTPUT BYTES REMAINING 
WAIT EQU CCA+40H 3; CHARACTER DELAY VALUE 

MSRSAVE EQU CCA+42H ; LATEST MODEM STATUS REGISTER 
INTFLAG EQU CCA+43H ; INTERRUPT ROUTINE FLAGS 

RXBUSY EQU 01H , RECEIVE INTRPT ROUTINE ACTIVE 
TXBUSY EQU 02H ; TRANSMIT INTRPT ROUTINE ACTIVE 
CRC EQU CCA+44H 3; CRC CALCULATION AREA 

RCRC2 EQU CCA+46H 3; SECOND RECEIVED CRC BYTE 

RCRC1 EQU CCA+47H ; FIRST RECEIVED CRC BYTE 

TCRC2 EQU CCA+48H ; SECOND TRANSMIT CRC BYTE 

TCRC1 EQU CCA+49H : FIRST TRANSMIT CRC BYTE 

RNEXT EQU CCA+4AH 3; CURRENT RECEIVE ROUTINE ADDRESS 
TNEXT EQU CCA+4CH 3; TRANSMIT ROUTINE ADDRESS 

RDISP EQU CCA+4EH ; RECEIVE INTERRUPT ROUTINE ADDR. 
TDISP EQU CCA+50H 3; TRANSMIT INTERRUPT ROUTINE ADDR 
DFLAG EQU CCA+52H 3 DISPATCH FLAG 

CRCTX EQU 01H ; CRC ROUTINE IN USE BY TX DISP. 
; ASCII EQUATES 

CR EQU ODH i ASCII CARRIAGE RETURN 

LF EQU OAH ¢ ASCII LINE FEED 

ESC EQU 1BH ; ASCII ESCAPE CHARACTER 

STX EQU 02H ; ASCII START OF TEXT 

ETX EQU 03H ; ASCII END OF TEXT 

DLE EQU 10H ; ASCII DATA LINK ESCAPE 

SYN EQU 16H ; ASCII SYNCHRONIZATION CHARACTER 
PAD EQU OFFH s TRAILING PAD CHARACTER 

TRUE EQU OFFH : FOR IF CONDITION TESTS 


FALSE EQU 


BUFFER VARIABLES 


0 


FOR IF CONDITION TESTS 


(RHR KKK KKK HIKE KEK HEE KEKE KKEKEHKKEKKEKKKKEKKEKKKKKEKEKKE 


Lael CONFIGURATION EQUATES ee 


; 
; ** VALUES CHANGE FOR EVERY CONFIGURATION belied 
| CRAIG IIII o ik Rk k k k 


FORMAT EQU WLS 1+WLSO s UART FORMAT (8 DATA, 


CVve 


0020 
OOFF 


27410 


0800 


0800 €31508 
0803 C34808 
0806 C30608 
0809 C3100A 


BAUDRAT EQU 


CUSHION EQU 


ACKTO  EQU 


3 NO PARITY) 
BAUD48 3 CURRENT BAUD RATE 


Wie be) ¢ THE MINIMUM NUMBER OF BYTES 
AVAILABLE IN THE TERMINAL BUFFER THAT 
3 ARE REQUIRED BEFORE A RECEIVE 

¢ OPERATION IS STARTED. 


=e 


3 ACKNOWLEDGE TIMEOUT COUNT 
3 (PRELIMINARY VALUE) 


-SeRESESELE SELES SEL ESE LSE SE SESE SEES ES SSS SESE PS SESS PSS 2? | 


ORG 


800H : THIS PROGRAMS EPROM START ADR. 


3 ENTRY JUMP TABLE 


080C 0C17564537RIMBUF DB 


0814 C8 


0815 380 
0817 D303 
0819 3520 
081B D300 
081D 3E00 
O81F D301 


0821 3E03 
0823 D303 


0825+20 
0826 E606 
0828 F608 


082A+30 


082B DBOO0 


082D 214309 
0830 224A10 
0833 211608 
0836: 229010 
0839 2T140A 
083C 224310 


083F 3E09 
0841 D301 


0843 3E04 
0845 D304 


084B C5 
084C DBO2 
084E FEO4 
0850 CA8A08 


JMP TJPINIT : INITIALIZATION ENTRY POINT 

JMP RST55 : INTERRUPT FROM 8250 

JMP $ : UNUSED INTERRUPT ENTRY POINT 

JMP DISPRX 3; TO DISPATCHER ROUTINE 

12,RIMD,'VE7APU' ¢ CONNECT BUFFER 

TERMNO DB 29 ia 3 THIS NODES TERMINAL NUMBER 
FOI IO IC IIR I IORI IOI TIO TO TIO TOO IOI TOTO IIT A ete tok tke 
TIPINIT: 

,c&T BAUD RATE IN SERIAL PORT 

MVI A, DLAB 

OUT LCR 

MVI A,LOW BAUDRAT 

OUT DLL * BAUD RATE DIVISOR LSB 

MVI A,HIGH BAUDRAT 

OUT DLM * BAUD RATE DIVISOR MSB 

: DEFINE CHARACTER FORMAT OF SERIAL DATA 

MVI A,FORMAT 

OUT LCR + UPDATE LINE CONTROL REGISTER 

s UNMASK INTERRUPTS FROM SERIAL INTERFACE 

RIM : GET CURRENT INTERRUPT MASK IN A 

DB 20H : READ INTERRUPT MASK 

AN1 000001108 : RESET RST5.5 MASK BIT 

OR1 MSE ; SET MASK SET ENABLE BIT 

SIM ; ENABLE RST5.5 INTERRUPTS 

DB 30H ; SET INTERRUPT MASK 

* CLEAR OUT RECEIVE BUFFER REGISTER 

IN RBR 


; SET UP INITIAL DISPATCH ROUTINES 


LX1 
SHLD 
LX1 
SHLD 
LXI 
SHLD 


H,EXIT 3 SET RECEIVE INTERRUPT TO IDLE 
RNEXT 


H,WAITLIP 3 WAITING FOR LIP BLOCK 
TDISP 

H’ WAITTB + WALTING FUR FREE CUSHION 
RDISP 


; ENABLE RECEIVED DATA AVAILABLE AND MODEM STATUS INTRPT 


MVI 
OUT 


; BRING 
MVI 
OUT 


A, ERBFI+EDSSI ; RECEIVE AND MODEM 


IER ; UPDATE INTERRUPT REGISTER 
UP RLSD (OUT1 = RLSD) 
MCR + UPDATE MODEM CONTROL REGISTER 


; RETURN TO LIP FOR COMPLETION OF INITIALIZATION 


RET 


KR KEKE KEKE KKK KEKE KE EEK REE KEKEKKEKKKKKKKKK KKK KKEK 


RST55: PUSH 
PUSH 
PUSH 
PUSH 
IN 
CPI 
JZ 


PSW 


; GET INTERRUPT IDENT INFORMATION 
TID1 3 RECEIVED DATA AVAILABLE INTRPT? 
3 GO TO RECEIVE INTERRUPT ROUTINE 


0853 
0855 
0858 
0859 
085C 


O85F 
0861 
0864 
0865 
0867 
086A 


086D 
086E 

0870 
0873 


0876 
0878 
O87A 
087Cc 


087D 
0880 

0882 

0883 
0885 
0887 
0889 


O88A 
O088C 
O88F 


0890 
0893 
0895 
0898 
089B 


089E 
08A0 
08A3 
08A6 
08A9 
O8AC 
O8AF 
08B2 


08B5 
08B7 
O8BA 
08BD 
08sco 
08C3 
08C6 
08C9 


08CC 
O8CE 
08D1 
08D4 
08D7 
O8DA 
O8DD 


08E0 


FEO2 
CA4909 
B7 
CA5F08 
C34309 


DB06 

324210 
AF 
E601 
C46D08 
C34309 


19 
E610 

CA7608 

C37D08 


DB01 
EOFD 
D301 

cS 


3A4310 
E602 


224A10 
C34309 


FEO2 
C2AC08 
21B508 
224A10 
C34309 
219008 
224A10 
C34309 


FE10 

CAC308 
CDEE08 
CA0609 
C34309 
21CC08 
224A10 
C34309 


FE1O 

C2E008 
CDEEU8 
CA0609 
21B508 
224A10 
C34309 


FEO3 


MSINT: IN 


CTSINT: MOV 


DI SABLETX: 
IN 
AN1 
OUT 
RET 


ENABLETX: 


1100 j IS IT TRANSMIT BUFFER EMPTY 
TXINT 3 GO TO TRANSMIT INTRPT ROUTINE 
A | MODEM STATUS INTERRUPT? 
MSINT ; TO MODEM STATUS INTRPT ROUTINE 
EXIT | UNKNOWN INTERRUPT, RETURN 
MSR | GET MODEM STATUS 
MSRSAVE ; SAVE MODEM STATUS FOR DISPATCH 
C,A | SAVE IT 
DCTS : HAS CTS CHANGED? 
CTSINT ; YES GO HANDLE CTS CHANGE 
EXIT 
A,c j GET MODEM STATUS BACK 
CTS ; TEST CTS BIT 
DISABLETX : OFF, DISABLE TRANSMIT 
ENABLETX + TRY TO ENABLE TRANSMIT 
IER : GET INTERRUPT ENABLE REGISTER 
OFFH-ETBEIL 
IER ; TURN OFF TRANSMIT INTERRUPTS 
INTFLAG ; IS TRANSMITTER BUSY? 
TXBUSY 

; NO, RETURN 
IER ; GET INTERRUPT ENABLE REGISTER 
ETBEI 
IER ; ENABLE TRANSMIT INTERRUPTS 


KKK EEE KEKE KEKE EERE EKREKEKKKKKKKKKKER 


RXINT: IN 
LHLD 
PCHL 


RSTART: CPI 


RSTX: CPI 


RSTX1: LXI 


RDATA: CPI 


RDATA1: LXI 


RCONTROL: 


JMP 
RCONTROL1: 
CPI 


RBR 3; READ DATA FROM SERIAL PORT 
RNEXT 7 GO TO ROUTINE ADDRESS IN RNEXT 


DLE 3 IS IT A DATA LINK ESCAPE? 
EXIT : NO 

H, RSTX s YES, NOW WAIT FOR START OF TEXT 
RNEXT 

EXIT 

STX ; IS IT START OF TEXT 

RSTX1 : NO 

H,RDATA ; YES, HANDLE TRANSPARENT DATA 
RNEXT 

EXIT 

H, RSTART s FALSE START GO BACK 
RNEXT ; TO BEGINNING 

EXIT 


DLE 3 IS IT A DLE? 

RDATA1 : LES 

RPUT ? NO, PUT DATA INTO BUFFER 
i 


RESTART ERROR, RESET BUFFER AND RESTART 
EXIT ; FROM BEGINNING 

H, RCONTROL 7; RECEIVE CONTROL 

RNEXT 3; CHARACTER NEXT 

EXIT 

DLE ; IS IT A SECOND DLE? 

RCONTROL 1 } NO, CHECK FOR: EIX 

RPUT 3 YES, PUT DLE IN BUFFER 

RESTART ; ERROR, RESET BUFFER AND RESTART 
H,RDATA 3; GO BACK FOR MORE DATA 

RNEXT 

EXIT 

ETX :; IS IT END OF TEXT? 


bre 


Q8E2 C20609 
O8E5 211D09 
O8E8 224A10 
08EB C34309 


O8F8+D7 


0906 3E00 
321C10 
090B 2A0410 


090EF+3E01 
0910+D7 
0911 220810 
219008 
224A10 
091A C34309 


091D 324710 
212909 
0923 224A10 
0926 C34309 


324610 
092C DB04 


0949 2A4C10 
E9 


0940 3E16 
094F D300 
215A09 
224C10 
0957 €C34309 


095A 3E10 
095c D300 
216709 
224C10 
0964 C34309 


0967 3E02 


RPUT: 


JNZ 
LKI 
SHLD 
JMP 


MOV 
LHLD 
XCHG 
LHLD 
INCTB 
MVI 
RST 
RZ 
SHLD 
MOV 
LX1 
INR 
MOV 
CPI 
RET 


RESTART: MVI 


RICRC: 


R2CRC: 


EXIT: 


STA 
LHLD 
INCTB 
MVI 
RST 
SHLD 
LX1 
SHLD 
JMP 


STA 
LX1 
SHLD 
JMP 


STA 
IN 

AN1 
OUE 
LDA 
AN1 


RESTART 3 NO, ERROR = RESTART 
H,R1ICRC ; NEXT RECEIVE FIRST CRC CHAR 
RNEXT 


EXIT 
C,A * SAVE DATA IN REGISTER C 
OTBE s PUT DATA INTO BUFFER 
TBIP 
1 
2 
: RETURN WITH ZERO STATUS IF OVERFLOW 
TBIP : UPDATE POINTER IF OK 
M,C : MOVE DATA INTO BUFFER 
H, BUFCOUNT 3 INCREMENT COUNT OF DATA 
M 
A,M 
251 | HAVE WE GOT 251 BYTES NOW? 
| ZERO STATUS IF TOO MANY BYTES 
A,0 * SET COUNT IN BUFFER TO ZERO 
BUFCOUNT 
CTBIE ¢ SET INPUT POINTER JUST BEFORE 
1 | DATA AREA 
A,1 
2 
TBIP 
H, RSTART : AND RESTART RECEIVER 
RNEXT 
EXIT 
RCRC1 SAVE FIRST CRC CHARACTER 


; 
H,R2CRC ; NOW GET SECOND CRC CHARACTER 


SAVE SECOND CRC CHARACTER 
RESET REQUEST TO SEND 


ve) 
Q 
ve) 
Q 
IN) 


OFFH=<RTS 

MCR 

INTFLAG ; INDICATE RECEIVE ROUTINE 
OFFH-RXBUSY }; IS NOT ACTIVE 

INTFLAG 
H,EXIT ; 
RNEXT 
EXIT 

B 

D 


IGNORE ALL RECEIVE INTERRUPTS 


H 
PSW 


T 
HI KH II IK KK KKK IK KKK IKK IKK KIKI RIKER ERE EEE EEE EREEREKE 
3 TRANSMIT INTERRUPT ROUTINES 


TXINT: 


TDLE 1: 


TSTX: 


LHLD 
PCHL 


MVI 
OUT 
LX1 
SHLD 
JMP 


MVI 
OUT 
LXI 
SHLD 
JMP 


MVI 


TNEXT 3 DISPATCH ADDRESS IN TNEXT 


A,SYN : OUTPUT A SYN CHARACTER 
H,TDLE1 3; NEXT SEND A DLE 


A,DLE 3; OUTPUT A DLE 


H,TSTX 3 NEXT OUTPUT START OF TEXT 


A, STX 3; OUTPUT START OF TEXT 


0969 
096B 
096E 
0971 


0974 
0977 
0978 
O979 


097C 35 


097D 


2A1A10 


0980+3E01 
0982+DF 


0983 
0986 


221A10 
7E 
D300 
FE10 
C24309 
21A409 
224C10 
C34309 
3E10 
D300 
21B109 
224C10 
C34309 


3E10 
D300 
217409 
224C10 
C34309 


3E03 
D300 
21BE09 
224C10 
C34309 


3A4910 


C34309 


3A4810 
D300 


CD7608 


TDATA: 


OUT 
LX1 
SHLD 
JMP 


LXT 
MOV 
ORA 
JZ 
DCR 
LHLD 
INCLB 
MVI 
RST 
SHLD 
MOV 
OUT 
CPI 
JNZ 
LXI 
SHLD 
JMP 


TDATA1: MVI 


TDLE: 


TETX: 


TICRC: 


T2CRC: 


TPAD: 


JMP 


THR 


H,TDATA 3; NEXT FUNCTION HANDLES TEXT DATA 
TNEXT 


EXIT 


H, OUTCOUNT ; MORE DATA IN BUFFER? 
M 
s 


TDATA1 3; NO, BUFFER EMPTY 
M 


LBOP = LBOP+1 


| OUTPUT DATA AT LBOP 

, IS IT SAME AS DLE? 
EXIT | NO 

3; TRANSMIT ANOTHER DLE 

3; TO MAKE TRANSPARENT 


OUTPUT A DATA LINK ESCAPE 


NEXT SEND END OF TEXT 


SEND DATA LINK ESCAPE 


AND GO BACK TO TRANSPARENT MODE 
TNEXT 


SEND END OF TEXT 


H,T1CRC : NEXT SEND FIRST CRC CHARACTER 


TCRC1 : SEND FIRST CRC CHARACTER 


H,T2CRC 3 NEXT SEND SECOND CRC CHARACTER 


SEND SECOND CRC CHARACTER 


SEND TRAILING PAD CHARACTER 


A, PAD ; 
THR 
INTFLAG ; MARK TRANSMIT NOT BUSY 
OFFH-TXBUSY 

INTFLAG 

DISABLETX 

EXIT 


SEND TRAILING PAD AFTER CRC 


FIR KK IKK KKK IK IIR KKK KR RK IKKIKE KR EEREEEEREREEEEEEEREEKKER 
7 CRC CALCULATION ROUTINE 


3; INCLUDES BYTE IN ACCUMULATOR IN CRC CALCULATION 
CALCCRC : PUSH 


MVI 
MOV 
LHLD 


CALCCRC1:EQU 


MOV 
RLC 
MOV 
MOV 
RAL 


PSW 


Gv'ce 


O9OF8 OF 
09F9 7C 
OOFA 17 
O9FB 67 
O9FC D2070A 
O9FF 7C 
OAOO 
OA02 67 
0A03 7D 
OA04 
OA06 OF 
QOA07 = 
OA0O7 05 
OA08 
OAOB 
OAOE F1 
OAOF C9 


0A10 
0A13 


0A14 2A0610 
OA17 EB 


OA18 2A0410 


OA1B+EF 
OA1C CA280A 


OA1F+3EFF 
0A21+D7 
OA22 DA120B 
OA25 2A0410 


0A28+3E01 


OA2B 
OA2E 
0A30 
0A33 F3 
0A34 
0A37 
0A39 
OA3C FB 
0A3D 
0A40 
0A43 
OA45 
OA47 
0A49 
OA4C 
OA4F C9 


3A4310 
E601 

C2120B 
3A5210 


2A4E 10 
E9 


0A50 
0A53 
0A55 
OA58 
OA5B 
OA5D 
0AG0 
OA63 7E 
OA64 
0A67 


0A68+3E01 
OA6A+D7 
OA6B 220810 
OA6E 210000 
OA71 224410 
0A74 217B0A 
0A77 224310 


MOV 
MOV 
RAL 
MOV 
JNC 
MOV 
XRI 
MOV 
MOV 
XRI 
MOV 


CALCCRC2: EQU 


DCR 
JNZ 
SHLD 
POP 
RET 


= @ 


Se 
CY my 


.- Om «= Ov 


DYrropmoaorom re 
Poiotypoog 


CALCCRC1 
CRC 
PSW 


(22222222 SSeS eeESEERE SESE ELE SEES SELES ELL SLES ELS S eee SS 2 


3? RECEIVE SIDE DISPATCH 


DISPRX: 


WAITTB: 


LHLD 
PCHL 


LHLD 
XCHG 
LHLD 
COMPARE 
RST 


LHLD 


WAITTB1: INCTB 
MVI 


WAITRX: 


RST 
SHLD 
MVI 
STA 


LDA 
AN1 
JNZ 
LDA 
AN1 
JNZ 
LX1 
MOV 
LHLD 
MOV 
INCTB 
MVI 
RST 
SHLD 
LX1 
SHLD 
LX1 
SHLD 


ROUTINES 
RDISP 7: GO TO RECEIVE DISPATCH ROUTINE 
OTBE | TERMINAL BUFFER CUSHION FREE? 
CTBIE 
COMPARE DE TO HL 
WATTTEA SAME, BUFFER AVAILABLE 


CUSHION } 
A, CUSHION 
2 


DISPTX ; 
CTBIE }; 


A,0 | 
BUFCOUNT 


INTFLAG ; 
RXBUSY 
INTFLAG 


H, RSTART 
RNEXT 


H, WAITRX 
RDISP 


INTFLAG ; 
RXBUSY 
DISPTX 
DFLAG 
CRCTX 
DISPTX 
H, BUFCOU 


Zw =e “8 NO 


’ 


CTBIE 
M,A 

1 

A,1 

2 
TBIP 
H,0 
CRE 
H,RXCRC ; 
RDISP 


=e "Se “we 


T 


IS -CUSHION. FREE? 


TO TRANSMIT ROUTINE DISPATCHER 
POINT TBIP JUST AHEAD OF DATA 


ZERO COUNT FOR RECEIVE ROUTINE 


RECEIVE ROUTINE IS ACTIVE 


3 START RECEIVING 


SET RTS SO OTHER END WILL SEND 


3 WAIT FOR BLOCK 


IS RECEIVER STILL BUSY? 


YES, GO TO TRANSMIT DISPATCHER 

GET DISPATCHER FLAG 

IS CRC ROUTINE BUSY? 

YES, GO TO TRANSMIT DISPATCHER 
3 COUNT OF BYTES RECEIVED 


POINT TO CURRENT INPUT ENTRY 


PUT COUNT IN BUFFER HEADER 
POINT JUST BEFORE DATA AREA 


INITIALIZE CRC VALUE 


NEXT CALCULATE CRC 


OA7A 


0A7B 
OA7E 
OA7E 
0A80 
OA83 
OA8 4 


C9 


211010 
7E 
B7 
CA970A 


30 
2A0810 


0A87+3E01 
OA89+D7 


OA8A 
0A8D 
OA8E 
0A91 
0A93 


220810 
7E 
CDECO9 
FE10 
CCECO9 
C9 
3E10 
CDEC09 
3E03 
CDECO09 
21A80A 
224510 
co 


3A4710 
CDEC09 
3A4610 
CDEC09 
21BBOA 
224310 
co 


204410 
7D 


B4 
C2D00A 
DB04 
EE01 
D304 
21D70A 
224310 
C9 
21140A 
224E10 
cg 


2A0410 
TE 


FEO7 
DA020B 


OAEO+3E08 
QAE2+D7 


QAE3 
OAE4 


we ape a Os 


21140A 
224E10 


Bed 


“2 21140A 


224310 
C9 


RET 
RXCRC: LXTI 
MOV 
ORA 
JZ 
DCR 
LHLD 
INCTB 
MVI 
RST 
SHLD 
MOV 
CALL 
CPI 
CZ 
RET 
RXCRC1: MVI 
CALL 
MVI 
CALL 
LXI 
SHLD 
RET 


CHECKCRC: LDA 
CALL 
LDA 
CALL 
LXT 
SHLD 
RET 
CHKFIN: LHLD 
MOV 
ORA 
JNZ 
IN 
XRI 
OUT 
LXI 
SHLD 
RET 
CHKFIN1:LXI 
SHLD 
RET 


H, BUFCOUNT 


A,M 


A 
RXCRC1 


A,M 
CALCCRC 
DLE 
CALCCRC 


A, DLE 
CALCCRC 
A, ETX 
CALCCRC 


H, CHECKCRc 


RDISP 


RCRC1 
CALCCRC 
RCRC2 
CALCCRC 


H, CHKFIN 


RDISP 


CRC 
A,L 


H 
CHKFIN1 
MCR 

DTR 
MCR 
H,RPROC 
RDISP 


H,WAITTB 


RDISP 


— a eo 


=e — 36 — Oe we 


e 
’ 


3 MORE DATA TO INCLUDE? 


NO, GO TO INCLUDE CONTROL CHARS 
DECREMENT COUNT 
UPDATE POINTER TO NEXT POSITION 


GET DATA BYTE INA 

INCLUDE IT IN CRC CALCULATION 
WAS IT DATA LIKE A DLE? 

DO ANOTHER FOR TRANSPARENCY 
RETURN TO LIP 

INCLUDE DLE AND ETX IN CRC 


, NXT CHECK THE CRC 
GO INCLUDE CRC CHARS RECEIVED 


INCLUDE RECEIVED CRC CHARACTERS 


# NEXT CHECK IF CRC IS GOOD 


GET CALCULATED CRC 
IS IT ZERO? 


NO, GO RESTART RECEIVE OPERATION 
YES, GOOD CRC, FLIP DTR 
PROCESS CHECKED BLOCK 


; BAD CRC, TRY AGAIN 


THIS ROUTINE SHOULD PROCESS THE BUFFER PREFIX 
TEMPORARILY IT ONLY PASSES THE BUFFER TO THE LIP 
AND HANDLES CONNECT/DISCONNECT 


; 

; 
RPROC: LHLD 
MOV 
CPI 
JC 
INCTB 
MVI 
RST 
MOV 
CPI 
JNZ 
MVI 
RST 
LXT 
SHLD 


RL eee 


RET 
CPI 
JNZ 
MVI 
RST 
LXT 
SHLD 
RET 


CTBIE 

A,M 

7 
RPROC2 
8 

2 

A,M 
"A'-40H 
RPROC1 
6 


H,WAITTB 


RDISP 


H,WAITTB 


RDISP 


— me 


=e '--%so eS O™. 


me NO “SD DE 


IS COUNT 7 OR MORE? 


NO, PASS TO LIP 
POINT TO SEE IF CONNECT OR 


DISCONNECT 
IS IT. CONNECT? 
NO, GO TO TEST FOR DISCONNECT 
0 FOR CONNECT 
COMMUNICATE REQUEST TO LIP 
; DON'T PASS THIS ENTRY 


IS IT DISCONNECT 
NO, PASS TO LIP 
YES, 1 FOR DISCONNECT 
COMMUNICATE REQUEST TO LIP 
3; DON'T PASS THIS ENTRY 


9D'¢ 


OBO2 2A0810 


0B05+3E01 
0B07+D7 
OBO08 220410 
OBOB 21140A 
OBOE 224E10 
0B11 C9 


0B12 2A5010 
0B15 E9 


0B16+E7 
0B17 C8 
0B18 3A5210 
OB1B F601 
OB1D 
0B20 7E 
0B21 


0B24+3E03 
OB26+DF 
O0B27 221A10 
OB2A 210000 
QOB2D 224410 
0B30 21370B 
0B33 225010 
OB36 C9 


0B37 211D10 
OB3A 7E 
NR3B B7 
OB3C CA530B 
OB3EF 35 
OB40 2A1A10 


0B49 7E 
OB4A CDECO9 
OB4D FE10 
OB4F CCECO9 
CB52 C9 
0B53 
0B55 CDEC09 
0B58 : 
OB5A CDECN9 
OB5D 21640B 
O0B69 225010 
0B63 C9 


Q0B64 3E00 
OB66 CDECONS9 
0B69 CDEC)D9 
OB6C 2A44}0 
OBG6F 224810 
0OB72 21790B 
0B75 225010 
0B78 C9 


0B79 3A4210 
OB7C E620 
OB7E 67 
OB7F 3A5210 
0B82 EODE 
OB84 B4 


RPROCZ2 : 


LHLD TBIP ; UPDATE CURRENT INPUT ENTRY 
INCTB 1 

MVI A,1 

RST 2 

SHLD CTBIE 

LX1 H, WAITTB ; NOW GO GET ANOTHER ONE 
SHLD RDISP 

RET 


FOO IO OI III RIO III III RR I aR KK 
; TRANSMIT SIDE DISPATCH ROUTINES 


DISPTX: 


LHLD 
PCHL 


TDISP 7 GO TO TRANSMIT DISPATCH ROUTINE 


3; THIS ROUTINE SHOULD PROCESS THE BUFFER PREFIX BUT 
; TEMPORARILY IT ONLY PASSES THE BUFFER TO THE HOST 
WAITLIP:NEXTIN 3: IS THERE A BUFFER ENTRY FROM THE LIP? 


TXCRC: 


TXCRC1: 


CRCFIN: 


STARTTX: 


RST 4 


RZ : NO, RETURN 

LDA DFELAG : INDICATE TX SIDE USING CRC 

OR1 CRCTX : ROUTINES 

STA DFLAG 

MOV A,M ; GET DATA LENGTH FROM HEADER 
STA OUTCOUNT ; FOR CRC CALCULATION ROUTINE 
INCLB 3 ; POINT JUST BEFORE DATA AREA 

MVI A,3 

RST 3 

SHLD LBOP * FOR CRC CALCULATION ROUTINE 

LX1 H,0 : INITIALIZE CRC VALUE 

SHLD CRC 

LX1 H,TXCRC ; NEXT START CRC CALCULATION 

SHLD TDISP 

RET 

LXT H, OUTCOUNT : ANY MORE DATA TO INCLUDE? 
MOV A,M 

ORA A 

dz TXC RC 1 3; NO, GO TO INCLUDE CONTROL CHARS 
DCR M : DECREMENT COUNT 

LHLD LBOP ; UPDATE POINTER TO NEXT POSITION 
INCLB 1 

MVI A, 1 

RST 3 

SHLD LBOP 

MOV A,M ; GET DATA BYTE IN A 

GALL CALCCRC ; INCLUDE IT IN CRC CALCULATION 
CPI Disk ; WAS IT DATA LIKE A DLE? 

CZ CALCCRC ; DO ANOTHER FOR TRANSPARENCY 

RET : RETURN TO LIP 

MVI A,DLE ; INCLUDE DLE AND ETX IN CRC 
CALL cALC c RC 

MVI A, ET 

CALL CALCCRC 

LXI H,CRCFIN ; NEXT TO FINISH CRC FOR SENDING 
SHLD TDISP 

RET 

MVI A,0 ; FINISH OFF CRC CALCULATION FOR 
CALL CALCCRC TRANSMISSION 

CALL CALCCRC 

LHLD CRC 2 SAVER CAULOLEAL ION CUR TRANSMIT 
SHLD TERE? 

Lod H, STARTTX ; NEXT, START TRANSMITTING 
SHLD TDISP 3 THE BLOCK 

RET 

LDA MSRSAVE ; SAVE CURRENT DSR LEVEL 

AN1 DSR 

MOV H,A 

LDA DFLAG 

AN1 OFFH-CRCTX-DSR 7; INDICATE CRC ROUTINE 
ORA H 3; NOT IN USE AND SAVE 


0B85 325210 
OB88 214D09 
OB8B 224C10 
OB8E 2A1610 
0B91 7E 

O0B92 321D10 


0B95+3E03 


OBY98 
OB9B F3 
OB9C 3A4310 
OBSOF F602 
OBA1 
OBA4 3A42 10 
OBA7 E610 
OBAQ CAB20B 
OBAC DBO1 
OBAE 
OBBO D301 
OBB2 FB 
OBB3 21BA0B 
OBB6 225010 
OBB9 C9 


OBBA 3A4310 
OBBD F602 
OBBF CO 
OBCO 211027 
QOBC3 224010 
OBC6 21CDOB 
QOBC9 225010 
OBCC C9 


OBCD 215210 
OBDO 3A4210 
OBD3 AE 
OBD4 E620 
OBD6 C2EA0B 
OBD9 2A4010 
OBDC 2B 
OBDD 
OBEO 7C 
OBE1 B5 
OBE2 CO 
OBE3 217908 
OBE6 225010 
OBES C9 


OBEFA 21160B 
OBED 225010 
OBFO C9 


OBF1 


STARTTX1: EL 


WAITTX: 


WAITACK: 


STA 
LX1 
SHLD 
LHLD 
MOV 
STA 
INCLB 
MVI 
RST 
SHLD 
DI 
LDA 
OR1 
STA 
LDA 
AN1 
JZ 
IN 
OR1 
OUT 


DFLAG 

H, TSTART 
TNEXT 
OLBE 

A,M 
OUTCOUNT 
3 

A,3 

3 

LBOP 


me "6 


=e me 


INTFLAG 
TXBUSY 
INTFLAG 
MSRSAVE }; 
CTS 
STARTTX1 
IER ; 
ETBEI 

IER 


=e 


H,WAITTX 
TDISP 


INTFLAG ; 
TXBUSY 


H, ACKTO 
WAIT 
H,WALTAC 
TDISP 


mu mens 


H,DFLAG ; 
MSRSAVE 

M 

DSR 
WALTACK1 
WAIT : 
H 
WAIT 
A,H 
i 


=e 


H, STARTTX 
TDISP 


¢ DSR IN DFLAG 

3; SET UP INITIAL XMIT 

, LNTERRUPT ROUTINE 
POINT TO DATA TO TRANSMIT 
GET COUNT 


DISABLE INTERRUPTS 
INDICATE TRANSMIT BUSY 


LS: lay UR? 


DON'T ENABLE TRANSMIT INTRPT 
YES, ENABLE TRANSMIT INTERRUPTS 


me 


ENABLE INTERRUPTS 
3; WAIT FOR TRANSMIT TO FINISH 


TRANSMITTER INTERRUPTS ENABLED? 


YES, RETURN 

NO, SET UP FOR TIMEOUT 

INITIALIZE ACKNOWLEDGE TIMEOUT 
7; NEXT WAIT FOR ACKNOWLEDGE 


IS DSR SAME AS BEFORE? 


: NO, BLOCK ACKNOWLEDGED 


YES, DECREMENT TIMEOUT COUNT 


IS TIME OVER? 


NO, RETURN 


; YES, TIMED OUT, SO SEND AGAIN 


; GOOD ACK, GET ANOTHER BUFFER 
: FROM LIP 


LINK LEVEL ADDRESS MECHANISMS IN AMATEUR RADIO PROTOCOLS 


by 


H. S. Magnuski, KA6M 
311 Stanford Avenue 
Menlo Park, CA 94025 


In October, 


for amateur packet radio networks. 
protocol is the set of address fields used at the beginning of each 


frame. This 


1982, agreement was reached on a new Link Level protocol 
One of the unique aspects of the 


paper reviews the types of addressing used prior to the 


adoption of the new standard, and explains in detail how the new 


address mechanism works . 


On October 9th, 1982, representatives of 
the active packet radio user groups throughout 
the U.S. agreed to establish a new _ standard 
for Link Level connections in the packet radio 
service. This agreement unified the 
development activities of several diverse 
groups, and provides for a point-to-point 
protocol which can be used both in terrestrial 
and satellite networking, This paper will 
review how addressing was done prior to the 


adoption of the new standard, and will then 
describe, in some detail, how the new address 
mechanism works, and what advantages and 


disadvantages are gained by adopting it. 


1.0 Background of HDLC Numerical Addressing 


The first byte of an HDLC frame following 
the opening flag is always an address byte. 
This byte permits a maximum of 256 stations in 
a network to be addressed, and sometimes less, 
as byte 00 hex is often reserved for special 
purposes, and byte FF hex is usually a 
broadcast (all-stations-addressed) address. 
Since 254 stations is a reasonable number for 
active stations on a single frequency 
metropolitan area net (metronet), the initial 
implementor of HDLC-oriented transmission, 
Doug Lockhart) VE/APU, decided that no more 
complicated addressing scheme was required and 
he programmed his Terminal ‘Node Controller 
board to deal with a = single byte address. 
Doug’s scheme initially utilized dynamic 
address assignment) and works as follows: 


When a station initially came on the air, 
it would send a special sign-on packet to a 
central control station, which would assign 
the next available numerical address to the 
new user. If the user logged off or timed out, 
the address would be put back into the free 
pool and handed to the next station to sign 
in. Once assigned an address, the’ station 
would use that address i-n all outgoing 
packets, and the central control station would 
know by that address who originated each 
packet in the metronet. All traffic flowed 
through the central control station, so there 
was no need for one remote to address another, 
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Several groups in Canada and the U.S. 
cesired to use Doug’s code without a_ central 
station, and _ so the following form of static 
addressing was adopted: 


Each user in a specific geographical area 
was assigned a numeric addl-ess, and that 
address was hard-wired int0 the outgoing 
eddress field of each transmitted frame. After 
é connect ion was made, the rece iving — stat ion 
would lock onto the’ transmitting station’ s 
address , and a.11 other packet:; on the channel 
would be discarded . 


variation of 
repeater 


The author implemented a 
this idea that would allow a simplex 
to ‘be used as part of a metronet. Some range 
of the address space, say 80 to 9F hex would 
be dedicated as repeater input addresses, and 
in repeating the packet the repeater would 
transform the address to the range 40 to BF. 
Thus a station would use address 01 for point- 
to-point work, and would use addresses 8} and 
Al for repeater uplink and down1 ink, 
respectively. 


The dynamic and static addressing; schemes 
described above served the early packet 
experimenters well, but it soon became clear 
that there were significant problems with each 
cf the methods . 


The dynamic addr2ssing scheme failed if 
the central control station failed, and many 
users did not want to be dependent on a single 
central repeater, The scheme did not allow for 
multiple repeaters serving a ziven area, and 
failed if there was any overlap in central or 
remote station RF domains, 


The static assignment method was just as 
bad, requiring an individual or club to 
prescribe addresses, and limiting the number 


of users to 62 if a repeater was involved. 
Visitors to an area might _ conflict with 
already assigned addresses, and using 
statically assigned addresses on a_ s:lobal 


satellite channel would be impossible,, 


Since neither of these methods would be 
workable over the long term, several proposals 
were put forward to correct the problem. 


2.0 HDLC Extended Addressing 


It became clear that if one could 
substitute a callsign for the hardwired 
numeric code, some of the addressing problems 
mentioned above would go away. The radio 
callsign is a unique identifier, and could be 
used to tag each packet being transmitted. So 
Terry Fox and others at AMRAD in Washington, 
Di; proposed to utilize the extended 
addressing feature in HDLC to incorporate the 
transmitting callsign. 


The HDLC standard permits an arbitrary 


extension of the address field through 
utilization of the least significant bit of 
the address byte as an extension flag. 


Basically, if the least significant bit (lsb) 
is zero, then the next byte forms part of the 
address field too, and one continues to extend 
the address field until a byte is found where 
the lsb is set to one. 


This 
implement, 


idea would be fairly easy to 
and did not require much overhead 
in each packet. It also did not violate any 
standards related to the HDLC Spec. 
Unfortunately, there were deficiencies in the 
method, particularly with regard to point-to- 
point addressing in a network, and flexible 
use of multiple repeaters in one RF domain. 
With just one address, a station could not 
target the receiver of an outgoing packet. 
Also, no provisions were made for dealing with 
multiple repeaters on the same frequency, and 
it became clear that this approach would have 
to be revised. 


3.0 The New Link Level Standard 


When the packet radio groups got together 
in October there was clearly an urgent need to 
agree upon a uniform link level standard, and 
to adopt one which would be sufficiently 
flexible to accomodate a variety needs and 
environments. 


Two proposals were put forward at the 
meeting, and it turned out that there was more 
in common in the proposed solutions than there 
were differences. The first proposal was by 
the AMRAD and New Jersey packeteers, and it 
was a result of extensive discussions on how 
to implement an X.25 type of service suitable 
for the radio community. This proposal, called 
AX.25, called for a destination and source 
callsign in an extended address field. The 
other proposal was from the author, and it 


also specified use of two or optionally three 
callsigns in the packet, but positioned them 
immediately after the control field. Each 


party was willing to compromise, the callsigns 
were kept in the extended address field, an 
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optional repeater address field was added to 
the AX.25 spec, definitions for bits in the 
sub-station and protocol ID fields were 
rearranged, and thus emerged the new standard 
protocol. 


4.0 Components of the Address Field 


As stated before, the standard protocol 
relies on the HDLC extended addressing bit to 
mark the end of the address field. The address 
field is composed of two or three seven-byte 
callsign address fields constructed in the 
following manner: 


CHARI] CHAR2 CHAR3 CHAR4 CHAR5 CHAR6 SSTD 


where each call is left justified in the 
field, padded with blanks, uppercase, and each 
CHAR is shifted left so that the lsb is zero, 
except for the last byte of the address 


fields, where the lsb is set to one, 
indicating the end end of HDLC extended 
addressing. The first callsign field is for 


the destination or 
second callsign field is 
transmitting station, 

field is for a repeater. 


receiving station, the 
for the source or 
and the optional third 


The SSID byte is of the form: 
Re. ol! SSoo 


where R is the "repeated" bit, set to one only 
in the optional repeater address field when 
the packet has been repeated. The '11' field 
is reserved and set to ones. It may be used 
for control purposes if required by a local 
area net. The SSSS field is the sub-station 
code, normally all zeros except for situations 
where a person has more than one station on 
the air. The X is normally zero, unless this 
field is the last of the callsigns, in which 
case it is set to one, indicating the end of 
the variable length address field. 


5.0 Uses of the Address Fields 


The simplest case is a point-to-point 


connection between two stations. Station A 
puts CALL B in the destination field, and CALL 
A in the source field. Similarly, Station B 


puts CALL A in the destination field and CALL 
B in the source field. When A receives a 
packet it first verifies that the frame check 
sequence (FCS) is correct. Next, it scans the 
address field to determine if the address 
field length is either 14 or 21 bytes. 
Assuming that the field is exactly 14 bytes 
long, it checks for CALL A in the destination 
field and for CALL B in the source field, and 
discards the packet if there is not a correct 
match. 


If a repeater is being used, the optional 
third address field will be utilized, and the 


following sequence of actions will take place: 


The transmitting station extends the 
address field to 21 bytes and places the 
callsign of the desired repeater into the 
third field. The I've-been-repeated bit (R 
bit) must be set to zero. The repeater is 
constantly monitoring the channel for packets 
and discards all packets which do not have a 
correct FCS or do not have exactly 21 bytes in 
the address field. If the third address field 
is present and if the call exactly matches the 
repeater's call and SSID, and if the R bit is 
zero, then the repeater sets the R bit to. one 
and retransmits the packet. The receiving 
station determines that the address field is 
exactly 21 bytes and checks that the R bit is 
set to one. If the R bit is zero it has 
received an uplink packet and should discard 
it. The receiving station then checks for 
proper source and destination callsigns, and 
accepts the packet on a proper match. 


The receiving station knows how to reply 
to an incoming transmission because an 
examination of the address field will inform 
it whether or not a repeater was used, and if 
one was used, its callsign. This information 
is used to construct the reverse path to the 
transmitting station. 


60 Limitations 


This protocol is intended only for point- 
to-point connections directly or through a 
Single repeater. The situation where multiple 
repeats are required is not covered and is the 
task of higher level protocols. 


The protocol also does not specify when 
the reverse path should be constructed. An 
implementor may decide to establish the 
reverse path only on information contained in 
the initial connect (SABM) packet. If so, and 
it the connector changes paths during a 
session, the two stations might be using 
different forward and reverse paths to talk to 
each other. 


The call signs add overhead to each 
packet (20 bytes at most), and these extra 
bytes will obviously slow down throughput. In 
doing link calculations, however, one finds 


that radio and modem turnaround delays are 
probably the most Significant factors 
affecting overall efficiency, and that the 
extra overhead of the callsigns are Justified 


in terms of the elimination of the requirement 
for a central control station, or elimination 
of any kind of connection-state information in 
the repeater. 


7.0 Summary 


The address mechanisms in this new 
protocol are fairly simple to implement and 
provide for a point-to-point connection in 
local area metronets, in backbone terrestrial 
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networks, and in satellite channels. The 
addition of a single repeater option makes the 
protocol useful for communications in a 
limited geographical area. The protocol will 
serve aS a building block for higher level 
connection-oriented protocols such as AxX.25, 
and can be easily used for connectionless, 
datagram-oriented protocols such as IP/TCP. 


REAL-TIME LOW LEVEL SOFTWARE ON THE TAPR TNC 


Margaret Morrison, 


4301 E. 
Tucson, 


Introduction 


This paper describes the low-level assembly 


language routines (LLR) of software released with 
the Tucson Amateur Packet Radio (TAPR) Beta Test 
terminal node controllers (TNCs). The primary 


functions performed by these routines are ini- 
tialization of peripheral devices and data in RAM, 
maintaining input and output (1/0) buffers, ser- 
vicing interrupts from peripheral devices, hand- 
ling nonvolatile RAM data storage and retrieval, 
and calibration and checkout routines. Entry 
points are provided which are appropriate to the 
subroutine calling sequence of the Pascal compiler 
used for the high-level routines  (HLR). In ad- 
dition, a low-level debug program provides capabi- 
lity for direct access to peripherals, inspection 
of RAM and ROM locations, and execution of tempo- 
rary code in RAM. The present LLR code occupies 
about six kilobytes of ROM. 


Initialization 


a RESTART interrupt by the 
processor, control passes to the low-level ini- 
tialization routine. This section first sets up 
the hardware stack, and then reads the on-board 
DIP switches which direct the initialization of 
user-settable parameters. These parameters, which 
can be set to their default values stored in ROM, 
or read from the 64 x 4 nonvolatile RAM, are 
decoded and expanded. The program initializes 
buffer pointers, counters, timers, and status 
flags, as well as non-permanent user-settable 
parameters. The peripheral chips are initialized 
and checked to verify that they can be commanded. 
If the UART can not be commanded, the program is 
aborted and another reset is attempted. Failure 
of other peripherals results in diagnostic mes- 
sages. The VIA timer functions are configured so 
that Timer 1 acts as a pulse generator for the 
HDLC controller and Timer 2 generates interrupts 
for software timing functions. The initialization 


On receipt of 


section terminates by enabling interrupts and 
typing a sign-on message, and passes control to 
the HLR. 


Buffer Management. 


One of the primary tasks of the LLR is main- 
taining the I/O buffers. At any time there are 
four active I/O buffers, input and output buffers 
for terminal and radio data. An echo buffer, 
which is configured identically with the terminal 
output buffer may also be present. Data received 
from peripherals (terminal and radio interface) 
are placed into input buffers which are read upon 
calls from HLR. Data placed into output buffers 
by calls from HLR are passed to the peripherals 
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under interrupt control. Fach buffer has an 
insertion pointer, which is updated as data are 
added to the buffer so that it points to the next 
available cell, and a removal pointer which points 
to the next cell to be read. All buffers are 
“circular”, meaning that each time a pointer is 
advanced it is compared with the top of the buffer 
space, and moved if necessary to the bottom of the 
buffer space. A buffer is "empty" when the inser- 
tion and removal pointers are the same, and "full" 
when the insertion pointer points to the next cell 
below the removal pointer. The incoming and out- 
going packet buffers contain, as the first bytes 
of each packet, the byte count of the packet. 


In addition to the two basic pointers, input 
buffers have other markers to facilitate input 


editing, and output buffers have space-available 
counters for use by routines writing to these 
buffers. 


A pointer to the beginning of an incoming 
packet serves two purposes. First, it allows an 
incoming packet to be purged in case of a_ recep- 
tion error (invalid frame-check sequence or 
insufficient buffer space). Second; it» -facrla= 
tates storing the byte count of the packet upon 
successful reception. 


The terminal input buffer management is 
rather complex, and operates in three different 
modes. In "command mode, " character and line 


editing functions are in effect,, and a pointer to 
the beginning of the current line insures that 
deletion past this point will not take place in 
case of rapid terminal input or slow input proces- 
sing. In *'conversation mode," an additional 
pointer marks the beginning of the current packet 
(actually the data portion of the packet), and an 
additional editing feature allows the user to 
cancel the current packet. Packets remain in the 
input buffer until they have been acknowledged, at 
which time the buffer is updated by a call from 
HLR. A completed packet is signalled by the re- 
ceipt of a packet-terminating character, and this 
character is placed in the buffer as a marker for 
the end of the packet. Inorder to prevent com- 
mands from interfering with partially typed pack- 
ets, separate input buffers are maintained, and 
the pointers for the active buffers are swapped 
when the mode is changed. This has the effect of 
from the inter- 


moving time-consuming decisions 
rupt dependent program to subroutines called from 
HLR. 

The third input mode is '*transparent mode, " 


in which all characters received from the terminal 
are transmitted. Packets are terminated on tthe 
basis of number of characters or occurrence of a 


Characters between the removal pointer 
marker are divided into maximum- 
with the remainder going into a 
In order to avoid ambiguity as to 
the packet marker is 


timeout. 
and the packet 
length packets, 
short packet. 
the composition of a packet, 


not updated until all outstanding packets have 
been acknowledged and cleared from the input 
buffer. 


Interrupt Service 


Although the 6809 microprocessor supports two 
levels of hardware interrupt, a fast interrupt 
(FIRQ) and a normal interrupt (IRQ), only the IRQ 
is implemented on the TAPR TNC. All peripheral 
IRQ lines are wire-ORed together into the IRQ 
input to the processor. Interrupt outputs from 
each peripheral can be disabled independently 
without affecting the processor's response to IRQ. 
Upon receipt of IRQ, the processor transfers exe- 
cution to a routine which examines each device in 
turn and passes control to a routine specified in 
a dispatch table* For maximum flexibility, the 
interrupt dispatch table is stored in RAM. The 
addresses in the table are initialized during the 
startup procedure, and are changed as_~ the INC 
operates in different modes. 


The peripheral devices are assigned priori- 


ties according to the order in which the dispatch 
routine checks their status. The priority of ser- 
vice is 


UART (terminal) 
UART output 

Timer interrupt 
All HDLC (radio interface) 


input 
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interrupts 


Interrupts from the parallel I/O port are not en- 
abled in the initial software release; when they 
they will be assigned lowest priority. The HDLC 
is currently assigned lowest priority because the 
interrupt service is quite complex and the chip 
will generate spurious interrupts at a high rate 
under noisy conditions. The UART was placed ahead 
of the timer, since the 6522 timer mode used pro- 
vides a mechanism for compensating for delayed 
interrupt servicing. The UART output ought pro- 
perly to be assigned a lower priority, but it was 
placed after the input service for convenience, 
since input and output status are given in the 
same register. Parallel port I/O must be assigned 
the lowest priority to insure that it does not 
interfere with other interrupt service. 


As a diagnostic tool, the interrupt dispatch 
routine writes signals reflecting interrupt condi- 
tions to the parallel port, which is configured as 
16 output bits for the initial software release. 


Terminal 170 


The terminal input interrupt service normally 
consists of two parts: an initial routine during 
which interrupts remain disabled, and a subsequent 
unprotected routine. The protected routine reads 
a character from the UART data register and places 
it in a temporary holding buffer, after which 
interrupts are enabled. This is because the input 
editing and echoing function is enabled upon re- 
ceipt of each character, and this can be a complex 
procedure in some cases. Depending on the input 
mode, the character may be tested against an 
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assortment of special characters, and this may 
result in flow control action or change of input 
mode. Characters which terminate packets or com- 
mand lines require that pointers be updated and 
flags set for other routines. Input editing char- 
acters cause immediate update of the input buffer. 
Finally, an echo routine is called, which places 
characters in an echo output buffer. Input char- 
acters are not echoed directly, since adequate 
terminal support sometimes requires that more than 
one character be echoed for each character input. 
In particular, automatic line feed after carriage 
return iS a common requirement, and some hard-copy 
devices require many null characters following a 


Carriage return. If the input buffer becomes 
nearly full, a request may be made to the output 
routine to transmit an XOFF character. Alterna- 


tively, a routine to produce the appropriate hard- 
ware flow control signals to the RS-232 interface 
may be called. 


Special input service routines are used when 
the program operates in "transparent mode." Since 
there are no special characters, the input charac- 
ter is simply placed in the buffer. A timer may 
be started, and a flag will be set if a maximum 
packet count has been reached. 


disabled when- 
and any routine 


The UART output interrupt is 


ever there is no data to be sent, 


which requests output enables the interrupt. Any 
special treatment of characters, such as conver- 
sion to upper case or adding line feeds or nulls, 


is done by the routine which fills the output 
buffer, which also maintains a screen-width 
counter and inserts extra carriage returns as 
necessary. The output service routine checks _ for 
tasks to be performed in the following priority 
and performs the first task found. 


XOFF character 
XON character 
in echo buffer 
in output buffer 


Request to transmit 
Request to transmit 
Transmit characters 
Transmit characters 
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If all tasks are exhausted, the routine disables 
the output interrupt. This is not necessary, but 
as long as this interrupt is enabled, the UART 
generates an interrupt at regular intervals. 


Timer Interrupts 


The basic function of the timer interrupt is 
to update the software clocks. The interrupt is 
set to occur at 10 ms intervals, which provides 
good resolution for timing associated with the 
radio interface. For longer times, a "slow" clock 
is updated at one-second intervals. An additional. 
10 ms clock is used as a pseudo-random number 
generator for determining packet retry times. 


In addition to the 'basic clock function, sev- 
eral tasks are performed under timer interrupt 
control. If a CW ]D is in progress, the Morse 
Code routine is invoked every 60 ms to toggle the 
tone on or off as necessary. Otherwise, a variety 
of tasks to be performed after time lapses are 
checked . Packet transmissions are begun following 
an appropriate interval following detection of a 
Carrier drop; and the ID is; sent at regular inter= 
vals. If a CW ID is commanded manually, it is 
begun in this routine. A special set of routines 
is entered when the program runs in "transparent 


mode, " and the appropriate routine is selected by 
reference to a status table. These routines mark 
packets for sending upon timeout of clocks which 
are started on character input, and set up guard 
times for the escape sequence for exiting this 
mode. 


HDLC Interrupts 


The WD-1933 HDLC controller generates inter- 
rupts for seven different conditions. Since any 
combination of interrupt conditions can be pres- 
ent, and most conditions are cleared by reading 
the status of the chip, all possibilities must be 
considered at every interrupt. The interrupt 
conditions are requests for service of input or 
output registers (DRQI or DRQO), transmission or 


receipt of end of message, with or without errors 
(XEOM or REOM), and change of state of carrier 
detect (DSC). 


Transmit interrupts, DRQO, XEOM-ok, and XEOM- 
err, are handled according to a state table which 
indicates the progress of the packet in transmis- 
sion. The appropriate action, as determined by 
the state table, is taken if any of these  inter- 
rupts is detected, without reference to which con- 
dition was indicated. The only transmit error 
possible is under-run, or failure to service a 
DRQO. This condition should never occur in normal 
operation. Following complete transmission of a 
packet and while final flags are being sent, the 
routine checks for further packets to be transmit- 


ted before the transmitter is unkeyed. The CW ID 
may also be started from this routine. 
Receive interrupts, DRQI, REOM-ok, and REOM- 


are handled according to the condition indi- 
cated by the chip status. In the event that more 
than one condition is present, a DRQI is assumed 
to precede an REOM, and the input register is read 
before closing the packet. If both REOM-ok and 
REOM-err are present, the error condition is. dis- 


err, 


regarded. Causes of the error condition are 
aborted frame, invalid frame-check sequence, and 
over-run (failure to service DRQI). The cause of 


the error is not investigated and any partially 
received frame is cancelled. Another possible 
source of error is insufficient room in the input 
buffer for the incoming packet. If the input 
buffer becomes full, a flag is set and the routine 
continues to read incoming characters as they 
appear, but an REOM-ok is treated as if it were an 


REOM-err. 


The DSC interrupt does not affect either 
transmit or receive operation. The carrier detect 
input of the HDLC controller is the demodulator 
lock-detect and is used to recognize a busy chan- 
nel. The service routine maintains software flags 
which reflect the carrier detect state, and if the 
carrier is found to have dropped, a timer is 
started which indicates when the next transmission 
may be started. 


Nonvolatile RAM Interface 


A number of user-settable parameters are 
stored in a semi-permanent state in the Xicor 
NOVRAM. To make maximum use of the 32 bytes of 
storage, the data is encoded in a compact form. 
In order to be useful to the program, it must be 
translated. The information stored includes ter- 
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baud rate and parity; 

baud rate, packet 
display fea- 
mode, auto 


minal attributes such as 
radio-link attributes such as 
length, and transmitter keyup time; 
tures such as case conversion, echo 
line feed, screen width, and nulls required. 
Special command characters for flow control, exit 
to command mode, and editing features are also 
stored, along with the station call _ sign. These 
parameters are changed by commands to HLR, which 
maintains the compressed copy of the parameters by 
calling LLR whenever a parameter is changed. This 
copy is overlaid on the nonvolatile storage as 
volatile RAM data, and becomes permanent when the 
"STORE" line is toggled. The nonvolatile RAM is 
controlled through the parallel I/O port of the 
6522 VIA. 


Calibration Routines __ 


The hardware design of the TAPR TPJC provides 
for on-board calibration routines. Jumpers are 
connected which allow the VIA Timer 2 to count the 
modulator or demodulator frequency to be calibra- 
ted. The VIA timers are reconfigured so that 
Timer 1 acts as a free-running count-down timer, 
counting at the 921.6 kHz system clock rate, and 
Timer 2 generates an interrupt after two cycles of 
the tone frequency being calibrated. By starting 
the timers simultaneously, Timer 1 can be used to 
count clock pulses for the duration of two periods 
of the frequency being calibrated. Two of the LED 
indicators a're controlled in parallel with the 
microphone audio and HDLC reset lines, and are 
used in this routine as visual indicators of fre- 
quency deviation from the desired values. The 
timer routines in the interrupt dispatch table are 
replaced with special calibration service rou- 
tines. 


High-level Interface 


Most of the entry points provided for HLR are 
concerned with buffer management. The I/O func- 
tions performed through these routines are: read 
a string from terminal or packet input buffer to a 
specified location; write a string from a_ speci- 
fied location to terminal or packet output buffer; 
return character count for an outgoing packet in 
the terminal input buffer; update terminal input 
buffer; and return space-available count for out- 
put buffers. Other functions provided are: up- 
date nonvolatile RAM, temporary or permanent mode; 
enter calibration routine; force CW ID; and per- 
form a soft reset. A special routine is called by 
HLR to notify LLR of a change of mode from "com- 
mand mode" to "converse mode" or "transparent 
mode." All routines are called with the addresses 
of the arguments in processor registers D, X, Y, 
and U as needed. 


Low-level Debug Program 


A debugging facility is provided in the LLR, 
primarily as a_ software development tool. This 
program is invoked by a special user-settable 
character. In order to preserve as much informa- 
tion as possible about the system prior to’ enter- 
ing the debugger, the active terminal input and 
output buffers are "frozen" upon entry by swapping 
the buffer pointers with a set of pointers used 
exclusively in the debugging program. All termi- 
nal input thenceforth is interpreted as commands 
to the debugger. These commands permit examina- 


tion or modification of any addressable location, 
modification of the processor registers as’ they 
were upon entry to the program, or transfer of 
execution to any location. This allows test 
routines to be stored in RAM and executed. The 
user also has direct access to I/O addresses, and 
can observe the contents of I/O buffers without 
interfering with them. 
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DESIGNING THE TAPR TNC AUDIO INPUT FILTER 


Margaret Morrison, KV7D and Dan Morrison, KV7B 
Holmes Street 
Tucson, Arizona 85711 

002-327-4775 


4301 E. 


Standard modulation for present terminal node 
controllers is Bell 202 compatible 1200 Hz / 2200 
Hz phase-continuous FSK. Fig. 1 shows’ the typ- 
ical spectral characteristics of such data. No- 
tice that frequencies ranging from about 500 Hz to 
2900 Hz are present in random NRZI data. One 
might guess that frequencies outside the central 
region from 1000 Hz to 2400 Hz could be eliminated 
with no degradation of demodulator performance. 


This turns out to be incorrect: the demodulator 
PLL needs this information to ensure timely re- 
sponse to data transitions. Thus, the ideal audio 


response over the link should be flat from below 


500 Hz to over 2900 Hz. 


In fact, the audio response of a typical FM 
2-meter link looks like Fig. 2. This response 
curve shows dramatic rolloff over the frequency 
range of interest. Most of the rolloff is due to 
receiver audio characteristics and, in fact, some 
transmitted signals actually seem more like phase- 


modulation rather than FM, with high frequency 
emphasis. In many cases, the demodulator on _ the 
TAPR TNC cannot handle this rolloff, and suc- 
cessful demodulation of these signals requires 
reduced baud rates. We decided to put in a filter 
ahead of the demodulator to alleviate this 
problem. 


The filter needed to take up as little space 
as possible, to be simple to modify, and most im- 
portantly, to be effective. In view of the fact 
that a variety of clock signals were already 
available on the TAPR TX, we opted for a 
switched-capacitor filter design, since ease of 
modification and parts-count make this a clear 
winner in the design competition. We quickly 
realized that in order t0 produce frequency 
compensation over a very wide range at least two 
sections would be required. Lyle Johnson, our 
hardware guru, thus selected the National Semi- 
conductor MF-10 dual section filter as the part of 
choice, leaving the design details up to us. 


Filter, Configuration 


This marvelous part may be configured in a 
number of ways as first or second order filter 
sections depending on external components, and 
each section may be configured independently of 
the other. After some experimentation we chose 
two second order sections -- one set up as a 
highpass filter, the other as a lowpass filter. 
This choice optimizes both amplitude and phase 
response over the wide range of frequencies 


required. 


The manufacturer's literature lists nine 
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different recommended configurations, each 
yielding a variety of output options. The choice 
is quickly narrowed to one, mode 3, which provides 
both highpass and lowodass outputs, and which pro- 
vides maximum flexibility in selecting filter pa- 
rameters. In particular, the frequency parameter , 
f0, is adjustable via resistor choices rather than 
by clock frequency alone. This, as well as’ dyna- 
mic range considerations, directed us to select 
mode 3 for both sections. In addition, we chose 
the option which scales f0 to fclk/100 rather than 


to fclk/50 in order to have as high a clock rate 
as possible. This allows’ the switching noise, 
which occurs at the clock frequency, to be most 


easily removed by post-filtering. 
Filter. Response 


The input section, configured as a highpass 
filter, is shown in Fig. 3a; the second’ secticna 
is configured as a lowpass filter, shown in Fig. 
3b. The frequency response for these two sections 
may be expressed as functions of frequency, f, and 


the parameters f0,9, and either highpass gain 
parameter GLP or lowpass gain parameter GHP. Let 
W= 3£/f0, where j*= -1. Then, the highpass 
filter's (complex) frequency response is 

ke 


hf) = Gue —— ———— 
wr + w/Qt { 


(1) 


and the lowpass response is 


h) = GLpe 


wr+w/ar4 


For either, the amplitude response ma; be 
determined as {h], and the phase response as 


Pout ~ Pin = arctan [Im (h)/ReCh) } (3) 


The parameters f0H, QH, and fOl, QL are 
related to the clock frequency, and the pro- 
gramming resistors, RZ, 23, and R4, by the 
following equations: 

aS | 
fo = felk A) RZ (4) 
100 RY 
ae | 
Gite. es Be (5) 
RQ RY 
where FO is fSH or £0L and Q is QH or QL, depend- 
ing on the section. 

For the highpass section, the gain is 
GHP = -R2/Rl1, while for the lowpass section the 
gain is GLP= -R4/Rl. Notice that for either 


section the input resistor, Rl, only affects the 
overall gain and does not influence the shape of 
the response. 


Optimization Procedure_ 


The design task begins by choosing f0H, QH, 
fOL, and QL’ so as to produce as flat an overall 
filtered response as possible given the unfiltered 
response. These four parameters are determined by 
successive interactive computer optimization of 
the filtered response .» A systematic search is 
made for the optimum parameters for each section 
alternately. 


The optimization of either section consists 
of a nested iteration which determines its Q in an 
inner loop and its £0 in an outer loop. The other 
section’s parameters remain fixed during this 
iteration. The inner loop calculates a _ least- 
squares straight line fit to the filtered audio 
amplitude response (expressed in dB), over a spec- 
ified range of frequencies, and varies Q to pro- 
duce a flat response., that is, best-fit slope of 
Zero. 


This procedure is written as a function whose 
value is the RMS deviation of the filtered re- 
sponse from the fit, and which also returns to the 
outer loop as arguments the value of Q, the slope, 
and the intercept of the fit. The outer procedure 
consists of a non-linear optimization (minimiza- 
tion} of the RNS error between the filtered re- 
sponse and the _ best-f it ting frequency-indendent 
response, as a function of the fU parameter. 


The specified frequency range for the calcu- 
lation can be varied to achieve best results. 
Typically, optimizing over the range 1000 Hz to 
2400 Hz produces very good results, as rolloff 
begins well outside the range of optimization. It 
is helpful to be able to graphically display in- 
termediate response curves during the optimization 
and to allow only inner-loop' iterations on 


occasion. 
Programming the Filter_ 


The remaining work is to determine the eight 
resistor values (four in each section) which best 
implement the optimized response functions. Sev- 


eral considerations allow a unique choice to be 
made . First, for best dynamic range in mode 8, 


fcelk/100 should be as near to f0 as possible. 
Since both sections run off the same clock, the 


optimum compromise clock frequency is the geo- 
metric mean, 


fole = AY Fou-for (6) 
100 
In practice, on the TAPR TNC this meant 


picking the nearest available frequency to this 


(fclk = 115.2 kHz), since the main crystal clock 
frequency is a power of two times any of _ the 
available values. Having selected the proper 


clock frequency we are able to determine the 
resistance values. This is done in the following 


steps: 


1. Notice that in either section the input 
resistor, Rl, does not determine response 
shape -- only overall gain of the stage. 
Using Eqs. (4) and (5) determine the ratios 


R2 : R38 
response, 


R4 which affect the shape of the 


2. Temporarily design each section so as to have 
unity amplitude response at 1200 Hz. Having 
thus determined the overall gain parameters 
GLP and GHP, determine the ratio of Rl to R2 
for the highpass section and the ratio of RL 
to R4 for the lowpass section ‘based on the 
gain-resistor relationships . 


3. Arbitrarily set the lowest resistance value in 
each section to 10 kilohms. This allows at 
least two of the eight resistors to be of gar- 
den variety. In addition, the resistances 
will be as low as possible while staying well 
above the minimum value recommended by the 
manufacturer (5 kilohms). Finish the design 
by using the ratios Ri : R? : R8 R4 to de- 
termine the remaining resistors. 


4. (Optional) To further ease the task of ob- 
taining resistor values, set both input re- 
sistors to 10 kilohms as well. Our expe- 
rience is that for the filters we arede- 
signing, this has littie effect on e:ther the 
dynamic range or the overall gain. 


The method outlined here efficient ly produces 
broadband designs. The result of applying this 
procedure to the unfiltered response shown in Fig. 
2 is shown in Fig. 4. The ampli t uce and phase 
response of this filter is shown in Figs. a and 
5b. Using optional step 4 above, the cverall gain 
of the highpass section is 6.73 and that of the 
lowpass section is 3,/3. The resis tance values, 
in kilohms, are: 


Highpass Lowpass 

R1 = 10.0 R1 = 10.0 
R2 = 63.7 R2 = 16.3 
R3 = 58.3 R3 = 10.0 
R4 = 10.0 R4 = 37.3 


A single FORTRAN program was written to per- 
form the design steps, menu driven and_ producing 
graphical display of the response as the design 
proceeds . A listing is available for the cost of 
photocopying, and the source is available provided 
a 9-track tape is sent to the authors.. 
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Figure 1. Typical spectral characteristics of random Bell 202 
compatible phase-continuous FSK data. 
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Figure 2. Audio response of a typical 2-meter FM link. 
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Figure 3a. Equivalent circuit for the input Figure 3b. Equivalent circuit for the output 
highpass filter section. lowpass filter section. 
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Figure 4. Filtered audio response of Fig. 2 
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PACKET RADIO FOR EMERGENCY COMMUNICATIONS 


Bob Neben, 
126 E, Schantz Ave, 
Dayton, Ohio 45409 


There is a need to redesign the techni- 
ques we use to handle emergency traffic. Many 
of us are combining processor controlled equip- 
ment and traffic handling techniques designed 
in the 1930! Se 


Traffic handling originated in radio, us- 
ing CW, a continuance from the landline systems, 
I presume. This limits ourcopy to about 15 to 
25 words per minute, depending upon the opera- 
tor's ability. The reliability of this system 
is very good since a CW signal can punch its 
way through a lot of QRM and QRN, Accuracy, 
however, is limited to the accuracy of the send- 
ing operator and the receiving operator, both 
of whom are subject to fatique. 


SSB or FM adds a new dimension, though, 
and we can talk about 150 to 200 words per min- 
ute. At these speeds, however, QRM is more of 
a problem. Also, we cannot pass traffic at 
that speed. Assuming we have to write the traf- 
fic on a message form, our speed decreases to 
about 25 words per minute, and we are really 
not much more ahead of the process than we were 
with CW, I remember copying MARS (Military Af- 
filiate Radio System) traffic, and whenever pos- 
sible, checking the addressee in the telephone 
book. It seemed more often than not that at 
least one digit waswrong. 


RTTY automates what we were doing manually 
at speeds of 60 to 100 words per minute. Rella- 
bility is about the same as voice, and accuracy 
is slightly better. Maintaining good accuracy 
requires careful tuning, listening for a “hit”, 
and human attention while typing. Generally I 
felt the accuracy of our MARS traffic left a 
lot to be desired. 


The type of traffic influences both speed 
and accuracy. Ragchewing requires neither 
speed, accuracy, orhardcopy. "Traffic", such 
as health, welfare, or greeting messages is 
different. Any media or system we use has a 
maximum capacity. Forinstance, suppose we are 
passing messages using 100 words per minute 
RITY, with no QRM, by continuously feeding paper 
tape to our TD (Transmitter Distributor). The 
system capacity would approach 100 words per 
minute in this case, and accuracy of the system 
would be very good. The dashed line (Figure 1) 
represents our system capacity. If we are using 
60 words per minute RTTY, voice or CW, the dash- 
ed line would represent a different system ca- 
pacity. Equally important though, is the type 
Of traffic. 
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Normal day-to-day message traffic such as 
MARS, demands only a small percentage of system 
Capacity. Even at peak periods. such as holiday 
traffic, it can normally be handled during the 
alloted time for the traffic net. In Figure l, 
traffic supplied equals traffic demanded, which 
is still below systmcapacity. System accura- 
cy is fairly good sine there is time for re- 
transmission requests and no one is under any 
particular pressure, 


Special events such as weather nets or 
public service events are difficult, asthe 
traffic is not constant. System _ capacity is 
still constraining us, and the traffic demanded 
begins, reaches a peak,and tapers off, (Figure 
2). In the caseeof a weather watch, t‘here is a 
scramble to get the watchers in position. Traf- 
fic builds as the NWS (National Weather Service) 
, EOC (Emergency Operating Center), or whomever 
we are assisting demands more information. usu- 


ally, just about the time information is most 
critical, such as when the storm is directly 
overhead, the system becomes overloaded, and 
traffic demands have exceeded capacity. What 


happens? Well, if the net _ control. can keep a 
cool had and the net is well disciplined, some 
ofthe more routine traffic becomesdelayed,. 
Accuracy decreases, however, and sorting prior- 
ities becomes a problem. Is the Mayor's "rou- 
tine" acted upon before the NWS "priority"? 

In time the delayed traffic is transmitted, but 
some of it will disappear, because it is no 
longer timely. This is not to imply it wasn't 
important, it was important, but we missed our 
chance. Somehow we need a better way of con- 
ducting traffic nets. 


Disaster nets have a terrible efficiency, 
(Figure 3). The traffic demands build to gar- 
gantuan proportions following tornado touch- 
downs, and other major events. We work our sys- 
tem to capacity, but it takes days and even 
weeks to chip away at the workload. Accuracy is 
horrible, and faith in the system and ‘amateur 
radio suffers in the long run. [I could justify 
this scenario in the 1930's, but what do we an- 
swer in the computer age? 


The answer to this problem is to move that sys- 
tem capacity line up so high that we couldn't 
run into it if we tried and at the sametime do 
error checking to insure 100% system accuracy. 
This is exactly whatPacket Radio will do for us 
in the amateur community, and it will do this 
at a relatively low cost. 


A Packet Radio station consists of your 


present rig (1930 vintage if you so desire, but 
preferably a modern FM transceiver), some kind 
of terminal or personal computer, and a TNC 


(terminal node controller), which does the pack- 
et formatting, error checking, and several other 
functions. Computers are becoming available 

for $100.00 and up, and TNCs, such as the one 
offered by the Tuscon Amateur Pack Radio group 
(TAPR), sell in the $200.00 range. So the cost 
to upgrade your station to Packet Radio is per- 
haps the cost of a two meter rig. 


Packet Radio will do a number of things for 
us. It will changethesystem capacity line 
from 100 words per minute in our example (74 
Baud) to 1200 Baud. On paper that's a sixteen 
fold increase. In reality, it will be less be- 
cause of packet overhead, but the increase is 
still phenomenal. The accuracy is virtually 
100%, because of error checking and system ac- 
knowledgements. Previously, the net controls 
could only talk to one station at a time. In 
Packet Radio, the 64 stations in each local area 
network (LAN) can send data to other stations 
Simultaneously. 


Computers don't have much effect on our 
present traffic systems, since human interven- 
tion is usually required to check status, stor- 
ed messages, etc. In Packet Radio, we have many 
uses for the computer. We could store messages 
for a station not yet logged in. We coulddo 
inquiries, such as health and welfare traffic. 
This may best be done computer to computer, 
which is fairly easy to set up. We couldtie 
our computer to others in the area over land 
line, or another frequency to handle incoming 
traffic. The possible uses for our home and 
club computers is seemingly endless. 


Our traffic nets are usually single func- 
tion; VHF for local, HF for large areas, etc. By 
using the gateway function, our LAN Packet Sys- 
tem can access worldwidevia satellite. This 
provides a means to get traffic in and out of 
the local system. Perhaps we need local sta- 
tions to handle the LAN. The other four sta- 
tions (or more) could link to other LAN's, gate- 
ways, computers, etc. 


What could happen if the national emergency 
evacuation plan were implemented? Imagine mov- 
ing 100,000 people in your community to an area 
50 miles away. It is logical that amateur radio 
would be used to help coordinate this massive 
effort. How would we handle this? The logistics 
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would involve massive vehicle movement, fuel, 
food, medical care, etc. Our present system 
wouldhave little usefulness, but a Packet 
Radio system couldeasily accommodatethis. If 
one LAN becomes overloaded, just initiate an- 
other. The gateways would also be heavily used 
and again, if a gateway becomes overloaded even 
at 19.4 K baud, another gateway would be ini- 
tiated. 


We are still using old technological equip- 
ment. Old technological traffic handling tech- 
niques are effective for day-to-day operation, 
but become overloaded at the first sign of large 
scale activity. We have the technology to cor- 
rect the situation, but we need to act now to 
adapt Packet Radiotechnology andprocedures to 
our traffic handling system. 


System Capacity = se Ses< 
Traffic Demands ——— 
Traffic Supplied 


\ 


Figure 1 Traffic handling during non-emergencies 


Figure 2 Special events and weather nets 


Figure 3 Disaster nets 
Traffic Activity Chart 
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MULTI--USE DESIGN CONSIDERATIONS FOR THE TAPR TNC 


Harold E. 


Price, NK6K 


2110Farrell Ave #14 


Redondo Beach, 


Abstract 


The Amateur Packet Radio Terminal Node 
Controller (TNC) built by TAPR Inc. is 
designed to meet the needs of a wide range 
of users, from the technical experimenter 
to the "appliance operator" end user. This 


paper discusses’ the human engineering 
factors which went into the design of the 
TNC's external software interfaces that 
enable it to serve a heterogeneous user 
base. 
Background 

The first Terminal Node Controller 
widely distributed for amateur use was 
produced by the Vancouver Area Digital 
Communications Group, Le was mainly 
distributed in bare-board form, and aside 


specialized HDLC communications 
chip, was able to be stuffed with readily 
available components. Once the user 
supplied a modem and power supply he had a 
device which required only a terminal and a 
radio to get on the air and send packets. 
The capability supplied by the VADCG TNC to 
newcomers in the field of packet radio far 
surpassed anything else available at the 
time, and has earned it its place in the 
Amateur Radio Hall of Fame. 


from the 


The TAPR TNC was designed to go beyond 
the capabilities offered by the previous 
ENC S$ ‘« Taking advantage of advances in 
technology, including the reduction in 
price of denser memories, the TNC hardware 
offered the following features: 


0 24K ROM 

re) Non-volatile RAM 

9) 6K RAM 

0 Onboard power supply with an off 


board transformer included. 
Onboard modem 

0 The TNC would be 
assembled and tested. 


offered 


The increased program space made 
possible increased software functionality. 
The increased level of pre-packaging would 
make the board attractive to an additional 
class of users, the "appliance operators". 
This term applies to that group of people 
who buy a product and expect to plug it in 
and use it. The term is sometimes used in 
a derogatory sense but’ that is not the 
intent here. This class of TNC user is not 
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interested in the underlying concepts and 
does not wish to tinker with the innards of 
the TNC. They accept packet radio as a 
proven technology and want to get on with 
the business of being end users, setting up 
higher level networks, establishing mailbox 
systems, building local area nets with 
intelligent host nodes and file servers, or 
Simply using the INC as error free RTTY. 
The TMC is a secondary item, simply a means 
to an end. 


This type of user would not be happy 
if he was required to modify source code 
and recompile to change node address, call 
Signs, and other operational parameters, 
On the other end of the spectrum is the 
experimenter, those individuals interested 
in tinkering with the lower levels. Many 
areas of amateur packet radio remain open 
issues, What are the best timing 
algorithms? What are the correct retry 
counts, timeout values, keyup delays, 
packet lengths and other details associated 
with the delivery of HDLC frames from one 
TNC to another? The functions offered by 
the TAPR INC “t0 sJlve these basic 
compatibility problems are discussed in the 
following sections. 


Conflicting Goals 


To illustrate the types of problems 
involved, the following items a re 
presented, each with its set of conflicting 
viewpoints. 


Degree of Transparency 


where the TNC is 
as a means for connecting two 
computer to computer or remote 
terminal to computer, the INC should be 
totally invisible. It can be viewed as a 
Simple modem, receiving characters from 
data terminal equipment (DTE) and sending 
it down a phone line, and receiving data 
from the line and sending it to the DTE. 
The TNC has no personality of its own, 


In. applications 
treated 
devices, 


In other applications, the TNC is 
itself the smart device at the end of a 
communications link, using a terminal only 
as an IO device under its control. The TNC 
performs local input editing and output 
formatting. It attempts to preserve visual 
fidelity on the terminal device, i.e., not 
mixing the echo of data being entered for 
transmission with data received from the 
vin ke 
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Command set 


Infrequent (casual) users require 
a simple command set with straightforward 
syntax and easy-to-remember english-like 
commands. Changing INC major operating 
modes should require a small number (one) 
of commands. 


users or those 
operational parameters 

This class of 
needing only a 
as the command 


Expert 
experimenting with 
require a rich command set. 
user also prefers commands 
small number of keystrokes 
entry rate is higher. 


Tuning Knobs 


Ths <2s closely related to 
command set, in that the more things there 
are to adjust, the more commands will be 
required to adjust them. 


To use a radio analogy, some hams 
are happy with ON/OFF, push to talk, and 


frequency tuning, others require variable 
bandwidth, IF shift (both high side and low 
Side), nocch, RF attenuation, multiple 


tuning rates, ten VFOs and snooze alarm. 


In addition, experimenters want 
access to all parameters which control 
forming, sending, and receiving packets. 


examples of the type of 
conflicting interests generated by a 
diverse user base. Availability of a 24K 
program space on the TNC coupled with the 
means to develop software ina high level 


These are 


language (Pascal) permitted the 
three-person software team to provide a 
Single integrated software package which 


meets everyone's needs. The major features 
of this design are discussed below. 


Definition of Terms 


Several of the shorthand terms used in 
the remainder of this paper are defined 


here. 

User interface. The asynchronous 
data path to the INC, the path used to 
exchange data which is formatted and 


the air. Configuration 
given to the TNC through 


transmitted over 
commands are also 
this path. 


Link interface. The: Jas stream 
(HDLC) path which connects directly to the 
RF transceiver. Rackets (frames) are sent 
over this path. 


A INC is "connected" 
the proper sequence 


Connected. 
when it has exchanged 
of packets over the link interface with 
another INC such that the two TNCs are 
connected at the AX.25 (or VADCG) level 2 
layer. Data sent by the TNC will be in the 
form of sequenced (numbered) information 
frames. Connected does not refer to any 
physical connections. 


Unconnected. The TNC is not 
"Connected" to any other INC. Data sent by 
it on the link is in the form of 
unsequenced information frames. 

Data transfer mode. Characters 
received through the user interface are 
assumed to be data for eventual 


link when the TNC 
When not in 


transmission through the 


is ina data transfer mode. 
this mode data input is assumed to be a 
configuration command. 


Operating modes 


The major point of difference between 
users of the TNC aus the degree of 
transparency of the user interface when the 
TNC is ina data transfer mode. Put nore 
Sirnply, is the TNC something one sveaks TO 
or speaks THROUGH? As stated previously, 
sorne users want to treat the TNC as a smart 
terminal, others view it as a smart modem, 
to be heard but not seen, Because of the 
large number of differences in basic TNC 
functions required to. satisfy these two 
needs, the TNC software supplies two data 
transfer modes. Entering one Of these 
modes has the effect of changing the values 
OL. *a large number OF configuration 
pavameters at once. The data transfer 
modes are the CONVERSATIONAL mode and the 
TRANSPARENT mode, and are abbreviated to 
"convers" and "trans" . 


Changing modes causes a radical change 
in behavior of the interface. Attributes 
of the INC in CONVERS mode are: 


input are scanned for 
implement f'eatures 


1) Characters 
special meaning to 
discussed below. 


2) Creation of packets is directly 
under user control. A special character is 
used to say "take the data entered 
previously, make it into a packet, and send 
it as soon as possible". 


3) Data can be edited until released 
to be made into a packet. Characters can 
be struck out, a line erased, or the entire 
packet can be erased. 


4) Data input is echoed locally, 


ies; “Dy the INC. 
5) Data received from the link is 
formatted before being output. 


6) Flow control is available via use 
of XON,'XOFF characters. Flow control is 
the process where data buffer or CRT 
display overflow is avoided by stopping the 
flow of data, The XOFF character is a 
request to halt the flow of data, XON is 
permission to resume t'he flow through the 
user interface. Case translation is 
performed, line feeds can be inserted in 
the data stream following carriage returns, 
Carriage returns are inserted when the 
output line length is exceeded. 
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The attributes of the TNC when in 


the TRANS mode are: 


1) All characters are transferred to 
the link without modification. 


2) Creation of packets is only under 
the indirect control of the user. Packets 
are formed by time or by data length. Data 
length control causes packets to be formed 
after "n" characters have been entered 
through the user interface. Time control 
will build a packet every "“n" seconds or 
after "n" seconds have passed since the 
last character was received from the user 
interface. 

3) Local echoing and local editing 
are not available. 


4) Data received through the link is 
transferred to the user interface as 
received, without modification or addition 
of control characters. 


5) Flow control is not controlled by 
data characters, but is managed by use of 
the standard RS-232 handshake lines. 


These two data transfer modes allow 
the TNC to be compatible with a wide range 
of applications. The behaviors described 
are present by default, they may be 
modified at will by the user. Functions 
can be added to TRANS mode, or removed from 
CONVERS mode, supplying a variety of hybrid 
semi-transparent or translucent modes. 

A third operating mode is present in 
the INC, COMMAND mode. Command mode is 
active when the TNC is first powered up, 
and can be entered from either of the other 


modes. COMMAND mode is used to change the 
configuration and operating parameters of 
the TNC. Changing the TNC from mode to 


mode does not effect the state of the link, 
i.e., whether or not the TNC is connected. 
This allows two personal computer owners to 
talk back and forth in CONVERS mode, and 
then enter TRANS mode to let their 
computers transfer files. 


A problem arises with respect to the 


total transparent mode. SHOLE OL a 
hardware reset, how is the command mode 
entered from the transparent mode? The 


method used to leave convers mode and enter 
command mode, a special control character, 


can not be used. Instead, a small 
compromise is made. After a user defined 
period (guard time) has passed where no 


characters have been received from the user 
interface the TNC will watch for a mode 
escape character. If this character is 
entered three times with no intervening 
characters, and another guard interval 
passes with no additional input, the INC 
enters the command mode. A proper 
selection of the guard time and escape 
character will provide a high probability 
that reception of the sequence is a valid 
request for command mode entry. Tas 


procedure did not originate with the TAPR 
TNC and aS a common practice for 
intelligent modems. 


Parameters 


There are many facets of the user and 
link interfaces that experimenter will want 
to twiddle with and the end user will want 
to ignore, or at most change only once. 
Examples of user interface items are: 


fy) Editing characters such as 
character delete, line delete, 
and packet delete. 


0 Flow control characters. 

0 Packet creation times in TRANS 
mode. 

i) Output presentation control such 
as <lf> after <cer>, number of 
nulls after <cr>, and terminal 


line length. 


Examples of link control items are: 


0 Transmitter and repeater keyup 
delays. 
fy) Number of times to retry a frame, 


frame acknowledge time 


i) Packet data size 

i) Maximum contiguous frames sent or 
maximum number of outstanding 
unacknowledged frames 

i) Station address or call sign. 


Previous amateur packet systems kept 
these parameters in ROM and supplied no way 
to modify them at- run-time. The TAPR TNC 
software embodies a design methodology 
where all such values are kept in RAM while 
the. . INC is running, and therefore can be 
modified by user command. The values are 
initialized from ROM when the TNC is first 
installed. The large number of parameters 
available to the user (see table 1) would 
require a very tedious startup procedure 


every time power was applied as not all 
users would be happy with the default 
values supplied in ROM. To~ avoid this 
unpleasantness, the TAPR TNC uses 


non-volatile RAM to store parameters when 
the TNC is turned off. A dip switch on the 
TNC selects either the ROM copy or the 
non-volatile RAM copy for initialization of 
the RAM parameters, After an initial boot 
from ROM, the TNC is then configured to use 
the non-volatile RAM for subsequent 


booting. 


This combination of software and 
hardware design permits hands-off operation 
for some users, one-time configuration for 
end-users, and endless opportunity for 
change by experimenters. 
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Commands 

The desire to have many user 
accessible parameters conflicts with the 
desire to have a_ small number of simple 


Since a major design goal was to 
many operational parameters 
was soon realized that the 
several commands. The Beta 
TNC software has 66 


commands. 
externalize as 

as possible, it 
TNC would have 

test release of the 
separate commands. 


Only four commands, the commands to 
connect and disconnect the link and the 
mode change commands, are used in normal 
operation of the INC. Most of the other 
commands are used to change parameters 
which have default values pre-assigned when 
the INC is first powered on. These values 
are satisfactory for most applications and 
will never be changed. If the parameters 
are changed, however, the user can issue a 
command that causes the changed values to 
be stored in the non-volatile RAM, 
replacing the default values. 


The command syntax is kept simple, 
consisting only *Ot the name of the 
parameter to be changed and the new value. 
A DISPLAY command is present which lists 
all parameters and their values. While not 
a replacement for a HELP facility, the list 
of parameters names serves aS a memory 
jogger and will cut down on trips through 
the manual. 


number of keystrokes 
needed, all commands can be abbreviated to 
a smaller number of characters that still 
uniquely identify the parameter, 


To reduce the 


Documentation 


As much care was taken with the design 
and implementation of the manual as was 
taken with the design and implementation of 
the hardware and software. The 
documentation must serve the same diverse 
user base the that TNC does. Because of 
the need to provide both tutorial and 
detailed information, the manual for the 
TNC iS approximately 140 pages long. The 
manual is structured to supply the right 


of detail at the right time. The 
few pages deal directly with the 
tasks required to get the INC’ on the air, 
including a detailed radio interface 
section. This detail is required because 
incorrect wiring of the TNC to RF interface 
can result in damage to the TNC and/or the 
RF gear. The introductory material is keep 
as short as possible however, and by page 
28 the user will be on the air sending 
packets. 


level 
first 


sections of the manual 
provide tutorial information on the 
hardware and on the protocols used. Other 
sections provide detailed information on 


Subsequent 


the software command set and on the TNC 
hardware. A full set of schematics is 
provided for hardware experimenters. Also 
included in appendicies are the 
specifications igen the communications 
protocols used on the TNC. These supply 
sufficient detail for others to implement 


compatible software. 


The manual is structured to supply the 
level of detail required by experimenters 
while at the same time not scaring off the 
casual user. 


Summary 


Great care was taken during the design 
and implementat ion of the TNC so-ftware to 
provide a simple interface for end users 
while not limiting the activities of more 
advanced users. The TAPR TNC is currently 
in a Beta Test phase with 180 users spread 
out in more than 16 local groups. It is 
expected that new commands will be needed 
while some current commands will prove to 
be superfluous and can be removed. The 
large percentage of high level code and 
human engineered design should make this a 
relatively painless task. 
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Command 


ABAUD 
ABIT 
AUTOLF 
AWLEN 
AX25 
AXDELAY 
AXHANG 
BEACON 
BKONDEL 
BTEXT 
CALIBRAT 
CANLINE 
CANPAC 
CMDT IME 
COMMAND 
CONMODE 
CONNECT 
CONOK 
CONVERS 
CPACT IME 
CR 
DEBUG 
DELETE 
DIGIPEAT 
DISC 
DISPLAY 
DWAIT 
ECHO 
ESCAPE 
FLOW 
FRACK 
HBAUD 
ID 

LCOK 
MAXFRAME 
MONALL 
MONCON 
MONF ROM 
MONITOR 
MONTO 
MYCALL 
MYVADR 
NULLS 
PACLEN 
PACTIME 
PARITY 
PASS 
PERM 
RESET 
RETRY 
SCREENL 
SENDPAC 
START 
STOP 
TRACE 
TRANS 
IXDELAY 
TXFLOW 
UNPROTO 
VDIGIPEA 
VRPT 

XF LOW 
XMITOK 
XOFF 
XON 


L - 
ce 


Link 
ING control 


= 
KK 
ae 

0 
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commands 


Function 
Asynchronous 'baud rate 
Asynchronous stop bits 


Follow received <cr> with <l1f> 
Asynchronous word length 

AX.25 or VADCG protocol 

Keyup delay time for audio repeater 


Audio repeater dropout (hang) time 
Beacon mode 

Echo <bs> when <del> entered 
Beacon text 

Enter hardware calibration routine 


Cancel line character 

Cancel packet character 

Command mode entry from TRANS mode timer 

Command entry from CONVERS mode character 
Default data transfer mode 

Connect TNC to another TNC 

Permits connections in unattended operation 
Enter CONVERSation mode 

Create packets by time in CONVERS mode 

Append a <cr> to the end of each packet in CONVERS mode 
Enter the debugger 

Specifies which of <del> or <bs> deletes characters 
Enables AX.25 digipeating function 

Disconnects the TNC from the link 

Displays all configuration parameters 

Digipeater wait time 

Local echo in not in transparent mode 

Character echoed when <eSc> is entered 

I/O data flow in CONVERS mode 

Frame acknowledge timeout 

HDLC (link) baud rate 

Send CW id 

Lower case translation 

Maximum unacknowledged frames 

Link monitor command 

Link monitor command 

Link monitor command 

Link monitor command 

Link monitor command 

Call sign (address) of this TNC in AX.25 mode 
VADCG protocol address byte 

Number of nulls added after <cr> in CONVERS mode 
Maximum packet data length 

Packet creation tine for TRANS mode 

Parity of asynchronous user interface 

Send next character verbatim in CONVERS mode 

Put current parameter setting in non-volatile RAM. 
Software reset 

Frame retry count 

Screen width for CONVERS auto-wrap feature 
Create packet character for CONVERS mode 

Flow control character 

Flow control character 

Link diagnostic command 

Enter TRANSparent mode 

Transmitter keyup delay 

Use character flow control in TRANS mode 
Unconnected address field 

Enables VADCG digipeater function 

Direct VADCG frames sen by this TNC to a digipeater 
XON/OFF or hardware flow control in CONVERS mode 
Enable transmit functions 

Flow control character 

Flow control character 


U - User interface 
D - Data transfer mode 


Table l. TNC commands 
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Packet Radio = A Software Approach 


Robert M. Richardson, FJ4UCI-I 
22 North Lake Drive 


Chautauqua Lake, 


Abstract: 


A software rather than hardware 
approach to synchronous Packet Radio 
communication at 1200 or 2400 Baud using 
the Radio Snack TRS-80, Model I or Model 
III microcomputer is described. The 
program duplicates virtually all the 
functions provided by the Vancouver Area 
Digital Communications Group (VADCG) 
terminal node controller board which 
requires an 8085 microprocessor, an 8273 
synchronous data link controller (SDLC), an 
8250 serial I/O, and a number of EPROM and 
RAM memory chips, plus a separate 
microcomputer with RS232C interface and a 
1200/2200 Hz modem. 


The only external equipment required 
by the software approach, other than a 
TRS-80, amateur VHF transceiver and 
antenna, is a port zero encoder/decoder, 
and two EXAR chips for AFSK keying and 
demodulation. The program has’ been 
extensively tested on the 2 meter amateur 
band working into southern Ontario and 
locally in western New York. 


Introduction: 
Packet radio communications is coming 


down the amateur radio pike in the near 
future, and the near future is now upon us. 


We have closely followed the evolution of 
amateur packet radio with its asynchronous 
beginnings in the Montreal area during 
early 1979 and its synchronous beginnings 


in the Vancouver area later in 1979/1980. 
The synchronous packet radio pioneers, 
including Douglas Lockhart VE7APU et al in 
the Vancover area developed the rightly 
famous and widely used VADCG terminal node 
controller board which was the introduction 
to synchronous amateur packet radio for the 
majority of all amateurs actively 
participating in packet communications 


today. 


Though a number of SDLC controllers in 


addition to the Intel 8273 are now 
available, such as. those from Western 
Digital and Zilog, and the price will 


hopefully be coming down as_- volume 
increases, there is yet another approach to 
amateur packet radio which due to its wo 
cost and simplicity, may greatly broaden 
amateur participation in this wave of the 
future. This approach is the software 
rather than firmware approach using a Model 


N.Y. 14722 


I or Model III TRS-80 with 48K memory and 
hopefully for convenience, 1 or 2 mini-disk 
drives. Sutiice: 2: oO Say, assembly 
language is used which offers nearly 3090 
times faster execution speed than standard 
Fortran, Pascal, or Basic high level 
languages. 


Even with the remarkable speed assembly 
language offers the user, it does require a 
finite amount of time in the receive mode 
for the program to serially accomplish what 
the dedicated SDLC chips are able to 
accomplish in parallel: i.e., find the last 
openning flag and address and store the 
packet bits in memory, convert the serial 
packet bits to decimal with zero deletion 
(the opposite of zero insertion), and do 


the CRC checking mens each frame. 
Nevertheless, this entire process for the 
average packet only requires 90 


milliseconds which is not a significant or 
even noticeable time delay to the operator 
at either end of the circuit. 


General: 


The program is comprised of 95 


segments: 


1. The transmit mode 
does the work horse job of 
prepared messages or programs, either 
keyboard or disk input, into IBM SDLC 
format, and clocking them out bit by bit 
serially at the desired Baud rate via port 
zero. Packet and frame length may be any 
length desired from 1to 250 bytes plus 
address, control and CRC bytes, and may be 
input from the menu. See figure 1. A 
total packet or frame length of 256 bytes 
will be allowed when intra repeater routing 
comes to pass. The extra two bytes will 
serve to determine routing. The number of 
preamble flags sent before the packet may 
also be programmed which is a courtesv for 
those with slow transmit and receive 
switching at the receiving end, A number 
of prepared messages may selected from the 
menu as well as keyboard input to memory 
for a nearly immediate packet. The video 
display utilizes the split screen format 
with the top 8 lines for receive and _ the 
bottom 8 lines for transmit. See figure 2. 


segment which 
converting 


Independent sequential scrolling is 
provided for both transmit and receive 
modes. 

a The cyclic redundancy check, 


2.67 


CRC16, segment which automatically 
generates the 2 byte CRC in IBM modulo 2 
format and appends these 2 bytes to each 
frame transmitted. This same subroutine 
serves the receive mode to check’ each 
incoming frame For CPC valicity also using 
the IBM modulo 2 CRC algorithm. which the 
dedicated SDLC chips utilize. 


3. 
software 


The receive mode segment has a 
equivalent of a digital phase 
locked loop which takes the serial packet 
input via port zero, and stecres each bit in 
memory either 8 bits per byte for best 
memory utilization, or 1 bit per byte for 
instructional purposes (easy to visualize). 
After the complete packet has been 
received, it is first converted from binary 
to decimal, then stored in high memory and 
displayed on video while the CRC test is 
being made for each frame if a multi frame 
packet was received. Depending upon 
whether the packet is of the unnumbered, 
supervisory, or information variety, 
appropriate action is taken automatically. 
The conventions followed are those used by 
the VADCG so the program is Eu dy 
compatible with those amateurs using the 
Vancouver terminal node controller. The 
program will receive and decode packets of 
any length up to the 12,288 byte capacity 
of the bit store allocation. Average 
packet decoding time after reception of the 


packet transmmission is 90 milliseconds, as 
previously mentioned. 

4. The edit/modify segment isa 
unique and extremely useful utility that 


allows the operator instant access to any 1 
of the 1024 byte, 60 pages of memorv in the 
TRS-80. Each page of memory is displayed 
at one time on the video display in TRS-80 
ASCII or graphics format. Fither upper 
case only, or upper and lower case 
edit/modify may be selected from the menu. 
Pressing the 'M' for modify key intiates a 
flashing cursor that may be moved up, down, 


left, or right on the displaved page with 
the arrow keys. Keyboard input ASCII value 
may be input directly if desired or 


"@' keys displays the 
memory value at 


pressing the shift 
memory location in decimal, 
this location, stack pointer value, and the 
operator asked to input the new value. Upon 
inputting the new value, the full memory 
page is displayed again, Pages are moved 


up or down through memory by pressing the 
BREAK key (flashing cursor disappears) and 
then the ENTER key to move up a vage in 


memory or the minus/DASH key to move down a 


page in memory. Needless to say, though 
ROM may be examined with this function, 
only RAM may be modified. To elininate 


tedious paging by hand, a number of control 
keys allows instant access to the more 
frequently used memory locations; il.e., 
transmit program store, received bit store, 
and received message store. 


and Morse 
subroutine 
of 


code I.D. 
This minor 
sends the Morse I.D. 


D5 Morse 
transmit segment. 


called by shift 'I' 
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the transmitting station at any speed 
desired to. satisfy F.C.C. requirements. 
Conversely, Morse code at any speed may be 
tranmitted from the keyboard via shift 


ra 
Memory Management: 


The operating program resides in 
memory from 29696 through 40959. Three 
12,288 byte segments are used exclusively 
by: 


A. 17408-29695 is reserved for the 
program or data to be transmitted store. 
Normally, a disk program to be transmitted 
via packet is first loaded from disk to 
40960+ in memory and then moved down to the 
17408+ area by pressing shift 'y'. In the 


"connected' mode of operation the program 
or data fron 17408+ is automatically 
transmitted in single frame packets of 254 


bytes length (a western New York convention 
so that a single station may NOT monopolize 
the packet repeater unfairly). This 
automatic transmission is called by 
pressing ‘Bs from the menu. 
Acknowledgement (ACK) packets are received 
automatically and if valid the next packet 
automatically transmitted, otherwise the 
previous packet is retransmitted. 


B. 40960-53247 is reserved for 
incoming received bit storage. We prefer 
to store abit per byte so that the user 
may visualize the stored bit pattern, 
though 8 bits per byte could be used for 
better memory utilization. Unless directed 
by the menu command to SAVE bit storage, 
this area is automatically cleared after 
each packet is converted to decimal and 
stored in high memory. Surely all you 
amateurs operating VADCG terminal node 
controllers know that it sends two SDLC 
logical zero 'bytes' AFTER the opening 
flags, which are then followed by a_ single 
flag BEFORE the address byte. Or did you? 
Packets less than 4 bytes total length, are 
ignored by the SDLC protocol that is used 
in this: program: 


Cs 53248-65535 is utilized for 
storing the converted decimal byte values 
from received packets. When it is full, an 
automatic 'not ready to receive’ (RNR) = 
'wait' is transmitted and when 
acknowledged, the operator may clear out 
all address, control, and CRC bytes by 
pressing '$' from the menu. Pressing shift 
'B' then takes the operator to DOS ready 
where the received program or data may be 
DUMPed to disk, after which one returns t 
the program, sends a ‘ready to- receive' 
(RR) to 'clear' the previous 'wait'" and 
continues upward and onward if it is indeed 
a program or data longer than 12,288 bytes 
bytes in length. 


Conclusion: 
Amateur radio has room for all types 
and varieties of individuals with 


dramatically differing interests. Some 
prefer operating and could care less how an 
electron gets from ‘'A' location to _ 'B! 
location and what is involved in getting it 
there, There is certainly nothing wrong 
with that, and to that variety of amateur 
we highly recommend the Vancouver terminal 
node controller kit *. With a few hours of 
soldering you are ‘on the air' using their 
EPROMs. To the variety of amateur who 
truly wishes to thoroughly understand how 
the absolutely brilliant IBM SDLC protocol 
operates, how to modify it for the 
forthcoming HDLC modes, we recommend the 
software rather than hardware approach. 
When you are done, you will not only be an 
"instant SDLC expert,' but a better 
assembly language programmer too. 


The software approach to packet ~ radio 
communications is obviously limited by the 
clock speed of the microcomputer being 
used. The Model I and Model III TPS-80 
will easily handle 1200 and 2400 Baud 
packets, with 4800 Baud packets being 


somewhat marginal but acceptable, without 
modifying the standard crystal clock of 
either microcomputer. By installing one of 


the numerous clock speed up kits available 
(4 MHZ), both 4800 and 9600 Baud packets 
could be handled. 


We are indebted to a number of our 
Canadian neighbors in the Hamilton and 
Toronto area for assistance in testing the 
software approach to packet radio. Most 
noteable have been VE3MWM, VE3DSP, VE3IUV, 
and VE3DVV. Their packet repeater located 
in the southern environs of Toronto with 
the apt call sign of VE3RPT is now active 
on 145.650 MHz. 


Locally (6.5 miles northeast of our 
QTH), the major effort to install a packet 
repeater in the greater Bufffalo area has 
been borne by W2EUP with considerable 
assistance from VE 3MWM, It will be linked 
to both the Toronto repeater to the north 
and a new packet repeater in the Syracuse 
area that will be able to link into’ the 
greater New York Citv area to the east, and 
thence linked up and down the east coast. 


We have only touched briefly on a few 
of the highlights of the software approach 
to packet radio communications. TO..g0 
through it in depth would take much more 
than the allotted space and _ time. For 
those who wish to explore the subject in 
greater depth, at least a few hundred pages 
worth, we suggest you watch for the new 
book, ‘The Packet Radio Handbook' that will 
be published spring '83 by Richcraft 
Engineering Ltd., #1 Wahmeda Industrial 
Park, Chautauqua, N.Y. 14722 at $22 
postpaid to the U.S. and Canada and $30 
postpaid overseas. 


* Vancouver Area Digital Comm. Group 
818 Rondeau Street 
Coquitlam, British Columbia 
Canada V3J 523 
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ENTER OPTION DESIRED ? 


CHANGE ADDRESSEE & NUMBER = A W2EUP CONNECT REQUEST CQ =B 
NOT CONNECTED TOGGLE SKC W2EUP DISCONNECT REQUEST = D 
SEND PACKETS FROM LO=-MEM = E W2EUP CONNECT ACKNOWLEDGE = F 
USING ONLY SOFTWARE MSG = G WORKING ON AMSAT AX, 25 MSG = H 
NOT INSERT DPLL BIT TOGGLE = I SEND HI-MEM CONTINUOUSLY = J 
NOW IN UFPER CASE MODIFY = K FILL HI-MEM WITH UWUUUU = L 
DISPLAY/EDIT MEMORY PAGE = M SET DISCRETE PACKET LENGTH = N 
LOAD HI-MEM ALL 11111 = O CHANGE DPLL TIMING VALUE: = p 
SEND CONTINUCUS FLAGS/126 = Q ABORT LO=MEM XMIT SEQUENCE = R 
MULTI-FRAME PACKET TEST = SG QUICK BROWN FOX TEST MSG = i 
CLEAR NON-PGM MEM 17K-605K =u INPUT/TRANSMIT MESSAGE = V & W 
ANY PACKETEERS ABOOT 255/0 = xX MOVE MID-MEM TO LO-MEM = Y 
NORM BIT STASH CLEAR = | MOVE RECV PACKS TO LO-MEM = 2 
SET NUMBER OPENING FLAGS = 43 WAIT & CLEAR WAIT TOGGLE = 4 
Figure 1 
1200 BAUD SDLC RECEIVE MODE ----> NOW CONNECTED 
1200 BAUD SDLC TRANSMIT MODE CONNECTED TO VE3MWM 


Figure 2 
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INTRODUCING THE PACKET ADAPTIVE MODEM (Pam) 


Paul i. Rinaldo., W4kI 
Amateur Radio Research and pee ePIC RECOnD: (AMRAD) 


P,Q. Drawer 6*2 
McLean, Virginia USA 22106 


Abstract 


This paper describes a modem design under- 
taken by Robert &. Watson and the author. The 
modem was designed primarily for high-frequency 
packet radio applications. It operates at signal- 
ane rates of 75, YL 500-500 and. 200 bauds. The 
data rate is software controllable through _a modi- 
fied ksS-232-C port. A frequency shift of oU0 Hz 
is maintained for alldata rates. |The modulator 
is phase continuous and provides X32 or Xo4_ clock 
to the packet assembler/disassembler PAD) or 
terminal-node controller (TNC). The demodulator 

mploys a National Mir1U switched-capacitor filter 
(see) chip for each of the 19UU0-Hz mark and 21UU0- 
Hz space frequencies. Bandwidths of the MFlUs are 
software controllable to accommodate different 
received data rates and receiver frequency toler- 
ances. A oint-to-point wired prototype of the 
modem has een built on an S-lU0 perf board. 
Power may be taken from the 5-100 bus or provided 
by a separate power supply. The prototype has 
been laboratory tested with excellent "eye dia- 
grams" on speeds up to 60U baud with some eye 
closing at 120U baud:;. Still pending _is a design 
decision whether to combine ah optimal minimun- 
shift keying (msk) demodulator circuitry for 12UU0- 
baud operation with this modem or to make it a 
separate modem. Uyvon completion pce boards and 
documentation will be made available to amateurs. 


Baudot Radioteletype = Some Background 


High-frequent (hf) baat (RTTY) 
using frequency-h iift keying(fsk) began in the 
U.S. Amateur Radio Service in. 1¥55 when the Fede- 
ral Communications Commissicn (FCC) authorized F1 
emission in the hf bands. Virtually all teletype- 
writers at that time were military or commercial 
urplus. They used a version of a five-unit code 
U.S. Military Standard or CCli™ International 
Telegraphic Alphabet No. 2) usually referred to as 
the Baudot or Murray code. Five-unit teletype- 
writers used since the 179Us in the_U.S. poe ly 
operated at a speed of 45.4bbaud (oust wom but 
a ew 50.9e-baud (7b.0%-wom) and 74.2-bau "(100- 
wen machines were also used. Tee availab le 

rom Huropean sources ran DUbaud (66.607 wpm). 


Many fsk demodulators (also called "tuning 
units" or TUs) were home-brewed by amateurs.s dow- 
ever, the design standards were those of military 
and commercial RTTY demodulators. In the 150s, 
the demodulators were normally designed to receive 
two audio frequencies separated by some multiple 
of 170 Hz, usually oD0 Hg. The favorite frequen- 

ies for many years were 2125 (mark and °2975 Hz 
space). in time, amateurs experimented with nar- 
rower shifts, aad eee 170 dz, using the audio 
frequencies 2125 (mark) and 2245 fig space), and 
standardized on it in the late 1970s. Today, 
virtually all amateur Baudot RTI'Y demodulators use 
17U-HgZ shaft although many also accommodate d5U- 
Hz and 425-Hzshifts as we ll. Many hf kTTY sta- 
tions use transceivers in the ssb mode, sending 
afsk into the microphone input of the transmitter 
and obtaining afsk output f'rom the receiver audio 
stages. Many of these transceivers start rolling 
their audio off not much above ¢V0UV Ga As a 
result the afsk frequencies 12/5 Hz (mark) and 
1445 (space) Ccalied the low tones) are also used 
and are standard in wurope. 


The majority of these afsk RTTY demodulators 
were designed as fm #demodulators. In this type of 
demodulator the signal is first sent through a 
bandpass filter to remove out-of-band interference 
and noise. It is then limited to remove amplitude 
variations. The signal is fm-demodylated in a 
discriminator or a phase-locked loop (PLL). The 
output of the detector is run through a_ low-pass 


fi.Lter to remove noise at frequencies above’ the 
baud rate. The result is fed to circuit which 
makes the decision between binary 1s and Us. 


ASCIL Radioteletype 


Effective March 17, 1980 FCC mles authorized 
the use of the American Standard Code for Informa- 
tion Interchange ASCiI) as defined in American 
ere aka Standard Institute (ANSI) Standard 4%3.4- 

Yoo. 


Straightforward asynchronous serial AsvII has 
not been. very popular on the ham band:; since it 


was legalized. This .is: -dué to 4 variety. of 
reasons. Some &TTYers own mechanical ceed age 
writers, mostly 45-baud Baudot. They cu rrertly 


are being phased out in favor of electronic digi- 
tal- terminals or computers which can communicate 
in either Baudot or ASCII. AM?UR is now added to 
the list of modes possible with "glass TTYs." 


Probably the reason why ASULI has not caught 
on in the hf bands :is that some amateu rs nave 
experienced poor results trying to operate jvUU- 
baud ASCLI. The lack of success is largely due to 
the modem design limitations. 


In order to operate existing Baudot demodula- 
tors at the higher signaling rates used in Asvll, 
it is necessary to raise the cut-off frequency ot 
the low--yass filter, and it may be necessary to 
redesign the bandpass filter and any filters used 
in” the “stector. The design can usually be 
stretched to conv 113 bauds. However, poor re~ 
sults can be expected when trving to modiry most 
17U-Hz, 45-baud demodulators to receive signaling 
rat es above 11U bauds. 


Other problems inlcude Re bade distortion 
due to multipath propagation. Wultipath can be 
recuced or eliminated by operating nesr the 
maximum-usable frequency (muf). These problems 
are discussed in. m pose given at the first 
packet Sonrevence, RES | 


Ameteur ARQ and FuC Hf RTTY Systems 


Although hf skywaverTTY is difficult:, high- 
uelity error-free operation has beenachieved by- 
fac robust systems using autoilatic -nyveat request 
AF) and forward error control (FC). Une 18 
AMTOR.L MARS1], |LFCC Ril-41 22}, [MbIs2 | Another 
experimental system was designedby Jerome Dijak, 
WY DL DId3l-33 4 
Amateur Hf Packet kxperimenta 
amateur hf packet 


Here is a summary of U.S. 
experimental contacts: 


On February 38, 1382 Ki RT in Connect-cut and 
W9LLO in California made a brief connection over 
20 meters using Collins KWM-3080s, Vancouver TNUs 
anc nf RITY modems. 


OnMay 31, 1982, KSMMOandW4kI, both in 
Northern Virginia, carried on a two-hour connec- 
ticn on 13 meters, at 12UJ bauds , using l0UM LU- 
7U1 > s, Vancouver TNCs and Bell 2VUd modems. 


On October 10, 1932, a1 5-minute connection 
tock place between W5lwWl in Waryland and and N5AnD 
in Texas using Vancouver TNCs and Bell 2Ué modems. 
Design Considerations 

Data Rates 


For this modem design, we are primarily 
concerned with signaling speeds which are feasible 
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through unmodified audio sections of 


for passin 
particularly hf-+ssb 


Amateur. nadie transceivers, 
transcelvers. 


The FCC rules permit up to 300 bauds on 
frequencies between 3.5 and 21.25 MHz, up to 1200 
bauds between 28 and _5O MHz, 19.6 kilobauds_ be- 
tween 50 and 220 and 56 kilobauds above 220 MHz. 


In addition to the Ad peas res tric- 
tion, the PUREE Signaling rate may be limited on 
hf skywave due to intersymbol distortion intro- 
duced bv multipath propagation. This and related 
subjects were analyzed in a paper I ninel at 
the first packet conference In 19381.,{RINS1 For 
some general rreading on the behavior of the hf 
ia medium for data communications see 
| BRAT |. 

a ce up to 1200 bauds should be prac- 
tical on the hf amateur bands whenever a usable 

requency exists near the maximum usable frequency 
enon At present, use of a 1200-baud signaling 
rate below 23 MHz requires a Special Temporary 
Authority (sea) from the FCC. I plan to apply for 
an STA in the near future. I also plan to inves- 
tigate the Peso pl i ty of a permanent rules change 
to permit up to 1200 bauds on all hf obanas 
including a portion of the 16U-meter band where F 
emission is not now permitted. 


At the lower end of the speed range, 
some consideration was given to including the rate 
of 57.5 bauds for those infrequent occasions when 
75 bauds can't be made to work due to intersymbol 
distortion. The speeds of 13.75 and 9.575 bauds 
could have been included but were rejected as 
being too slow. 


_.. We decided to make the speeds 75,150, 
300, ©00 and 1200 bauds. These five speeds are 
selected bY means of on-board solid-state 
Switches. he modulator clock output rate is 
controlled by a 4512 83-channel buffered data se- 
lector. Filters in the demodulator are set by_six 
4051 single G-channel analog miltiplexer/demilti- 
lexers. These seven chips are controlled by 
hree lines from the PAD. 


Using five speeds and having an 8- 
channel switching capability permitted the inclu- 
sion of wider bandwidths for the three slower 
speeds of 75, 150 and 500 bauds. The wider- 
bandwidth capability is to make allowance for 
frequen¢ev error. This is particularly useful when 
the receiver s pee eee. is di ga tally pip eloe ce 
and/or left unattended. The ICOM IC-720A is sub- 
ject to a frequency error of +50 Hz when 
externally controlled. Un the other hand, a no- 
compromise narrower bandwidth can be selected when 
the receiver is front-panel controlled, thus set- 
table to within +5 Hz. 


Frequency Shift 


The i/70-Hz shift in common use for 
Baudot RTTY could be used for data rates of 7/5 and 
150 bauds with signal-to-noise (S/IN ratios common 
on amateur hf RTTY. Use of this shift at 300 
bauds has been done with some sacrifice of 
demodulator error pert ormance: It is not suitable 
for the speeds of 600 and 1200 bauds. 


When the narrower shifts (say below 400 
Hz) are used, there is a tendency for the mark and 
space frequencies to fade dependently fosetien). 
So, if one fades, the other is likely to fade at 
the same time. The mark and space frequencies 
tend to fade more independently when the shift is 
wider. Independent fading is common at the age-~ 
old shifts of 425 and 350 Hz, with more indepen- 
dence obseved for 850 Hz shift. Some commercial 
RTTY demodulators make use of this so-called in- 
band frequency diversity and use combining and/or 
selection peu das to continue cojying even if 
one frequency or the other fades completely. 


We have chosen a shift of 600 Hz for two 
reasons. One is that there is enough frequency 
separation to permit good in-band frequency diver- 
sity action. Also, the Se Une of 600 Hz 
is directly related to the baud rates and permits 
phase-continuous modulation and synchronous de- 
modulation. At 1200 bauds, a 6Q0-Hz shift is 
called minimum-shift keying (msk) or sometimes 
fast frequency-shift frsk) to connote that the 
shift is less than 1 Hz per baud. 
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Phvsical Construction 


We decided tc use an (IEEE 696) S-100 
card for the modem. This 5- x 10-inch board was 
about the size needed for all the ctipss if 4 
double-sided printed wat ne is used. The modem 
can be plugged into an S-700 computer frame and 
take power from the bus. Or it can be mounted in 
its own box with a se arate power es yl if de- 
ie None of the S-] 00 data or con ro lines is 
used. 


Having tasted the fruits of receiving 
RTTY with a polarization-diversity setup, I plan 
to build a second PAM board for the second demodu- 
lator channel. One demod will be fed by an IC- 
720A transceiver, the other_by_an IC-R/7U receiver. 
I also. just purchased an IC-707e2 interface unit 
which slaves the two together. The first PAM will 
have the modulator and a demodulator. The second 
board is to have an identical demodulator (saie pe 
Peo and, in the piace of the modulator, a 
iversity selector to process the outputs of the 
two demodulators. 


Input/Output Connections 


The (data) I/O connection to the PAD 
follows KIA RS-232-C rules with the exception that 
the three data-rate control lines Guane 8, 23 and 
25) are presently at TTL levels to reduce the PAJ) 

pip count. nsulation-displacement connector 
(ID ) headers are used_on both the PAD and PAW 
boards rather than the bulkier D3-25. If there is 
need to route_this 1/0 outside the cabinet, a 
cable with an IDC plug would connect to a back- 
panel-mounted DB-25. 


The (analog) I/0 connection to the radio 
is to be done with an IDC header. Work remains to 
be done on the radio side of the modem to ensure 
compa yea ty with various amateur hf radios. The 
goal is to devise an interface scheme that will 
permit the greatest flexibility. 


The interfacing of the, transmited analog 
(TxA) and received analog (RxA) signals is only a 
matter, of adjusting levels and keep irg unwanted rf 
at arm s length. owever, the IC-72CA and the IC- 
R70 (and some other ICOM radios) have a 24-pin 
accessory connector which permits digital remote 
control of frequency. As some external control 
circuitry is needed for the ICOMs, one of my 
future projects ae, be to design a Receiver In- 
terface Board (RI3) to go between the modem and 
the radio(s) when [COMs are used. The RIB will 
also be built on an S-100card. As the RIB will 
be optional, the connector scheme will be designed 
to work with the RIB or without it. 


The I/O design has been deferred unti 
receipt of a Tuscon Amateur Packet Radio (TAPR 
beta test model TNC. ia khou sh designed as a 
companion modem for the AMRAD PAD, the goal is to 
make the PAM usable with a pret Site Vancouver 
and TAPR TNCs before the I/O design is finalized. 


Circuit Description 


Fig. 1 shows the shematic of the PAM as of 
this writing. CMOS logic integrated circuits are 
used throughout. 


Modulator Circuitry 


A 2,6088-MHz ory ovat master clock feeds 
two divider chains. This crystal is not on a 
stock frequency and was ordered from a crystal 
manufacturer. 


The U2-U6 chain divides by 32, then 
divides by / for mark or 5 for space. U4 divides 
by 3 and feeds its outputs to two UD Ex-OR gates 
to produce a stepwise approximation a a sine wave 
at either 1500 Hz (mark) or 2100Hz (space). The 
Uo active filter removes the steps to produce a 
sented Sinusoidal output to modulate the trans- 
mitter. 


The other divider chain produces either 
X64or X32 clock for the PAD or TNC_ respectivel 
for the signaling rates of 75, 150, 300 ,f00~ an 
1200 bauds. The binary counter delivers a 
number of outputs which correspond to X64 clock at 
each rate. These outputs are selected by Ui0o.w A 
a2 aes tins counter of U4is used for an X32-clock 
output. 


Demodulator Circuitry 


A commonly stocked 2.097152-MHz crystal 
was used as the master clock to 49.94 times the 
center frequencies of the two M10 filters. This 
stock crystal (and divider chain) just happens to 
clock the MF10O filters for center frequencies of 


_. U109 is the MF1O space filter, U110 the 
mark filter. Both sections of each MF1O are used 
to achieve a 4th-order bandpass filter with stee 
skirts to cope with hf band crowding. Four 405 
8-channel analog mu preter. U105-U108, select 
resistance values which set filter bandwidths. 


_ The first halves of Uili and Ulle 
are active low-pass filters for the mark and space 
tones and provide feedback to the MF1Os to reduce 
tilt. The other halves are full-wave detectors. 


The first half of U113 sums the detected 
outputs and does some low-pass roll off. The main 
post-detection low-pass filtering is accomplished 
in the second half of U1135 with U114 an 
there to switch resistor values according to baud 
rate. U116's two halves are positive and negative 
peak detectors. 


2 One half of U117 is acomparator for the 
poor e and Hepat iN Aves and feeds the RxD to 
he PAD via part of U5 which can be used to invert 
data. Inverting data is not necessary when NRZI 
eucogias is used but may be needed for NRZ-encoded 
Signals. 


_ The other half of U117 is a tuning indi- 
cator circuit. An on-board LED is switched in for 
testing and out when an external LED is connected. 
Here s_how to use it: While tuning the receiver, 
control the input level (RxA) for less than half 
brightness. Tune for maximum brightness, reducin 
the receiver gain as necessary.Increase the inpu 
signal level until a maximum is reached, then back 
it off to half brightness. 


Of course, an oscilloscope would provide 
a better tuning ae One can be connected at 
Poi nus X and Y fed by the first halves of U111 and 


Semiconductors 

Qi 2Ne2e2 npn transistor 

U1 ,101 CD4049 hex inverting buffer 
U2,9,102 Cb4024 ‘7-bit binary counter 
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U3,7,8,103,104 CD4029 presettable binary/decade 
up/down counter 

U4 CD4520 dual binary counter 

U5 CD4077_ quad ex-OR 

Uo LM/41CN op amp 

10 CD4512 8-channel data selector 

41 MC1489 RS-232-C receiver 


U12 MC1488 RS-232-C driver 
U105-108,114,115 CD4051 single 8-channel analog 
mul piercer iomile eicrer 


107,108 MFIOBN universal monolithic dual 
__ switched capacitor filter 

U111-113 MC1458 op amp 

J116,117 TLO82 op amp 
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Abstract 


SOFTNET is a packet-radio concept under 
devel opnent in Sweden. The netvork is distri buted 
and all nodes are progrannable via the netvork 
during nornal operation. This concept represents 
an unconventional approach to the protocol issue 
and offers elegant solutions to the higher | evel 
connuni cation problens. This paper gives a 
progranmng nodel of the netvork, along wth sone 
illustrating exanpl es. 


|. I[ntroducti on 


The SOFTNET approach was concei ved in 1980 
and discussed anong Swedish radio anateurs. The 
discussion led to a proposal for an experi nental 
network in the 432 Mt band utilizing bit rates 
up to 100 kbps. During 1981 this draft was 
presented to the Swedish Tel econnuni cati on 
Admnistration. The Admnistration responded in a 
positive way, giving the packet radio group at 
Linkoping University virtually free hands. This 
group, consisting of 6 people, is currently 
invol ved in devel oping prototype nodes and basic 
software for the netvork. 


The nain concept behind SOFTNET is that all 
packets are considered to be prograns of a 
network | anguage. These prograns are interpreted 
in the nodes as soon as they arrive. Nodes can be 
progranned by any nunber of users si nul taneousl y 
wthout unwanted interaction. This approach nakes 
it possible for a user to define his ow high 
level services like datagrans, virtual calls, 
file transfers and nail boxes. The concept also 
allows changes at lover levels during operation, 
permtting redefinition of LINK-level/Access 
protocols. A detailed description of these ideas 
can be found in / 1],[2],[3],[5]. 


Il. Node nodel 


In a SOFTNET node, an incoming packet that 
has passed the link level is given to the node 
conputer for interpretation. Here, a standardi zed 
set of instructions are available. The kernel of 
this set is sinply a FORTH interpreter to which 
has been added functions that control the node 
hardware. Thus, any user nay execute his own 
FORTH programin any of the nodes that he can 
reach. This way he is able to instruct another 
node to either deliver the packet to the ower of 
that node or to retransmt it so that the node 
nerely acts as a repeater. FORTH allows the 
Ssreation of private directories so the user nay 
‘lso store prograns in renote nodes. These 
rograms may either wake up upon the arrival of a 
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packet fromthe user or upon an internal signal 
(e.g. the real tine clock) produced by the 
renote node itself. Describing the node thus 
reduces to describing a progranmng nodel. In the 
FORTH case, this is done by sinply listing all 
the available functions or "words". [4].Fig. 1 
sunmarizes the packet fornat fromthe user's 
poi nt of view 


an, 


Nc, 
link | evel link level 
i nf ornati on i nf ornati on 


Fig. 1. ASOFTNET packet 


In fact, the link level protocol has been 
added to the FORTH kernel so that also the link 
level infornation is handled by a FORTH 
interpreter. This pernits on line reprogranming 
and extension of the link protocol such as new 
version of HDLC, access algorithns etc. Thus, 
fromthe first byte to the last, a SOFTNET packet 
is sinply a set of FORTH statenents. From a 
practical point of viewit is a good idea to 
conceptually keep instructions at the link | evel 
apart fromthe higher level prograns since 
changes at link level have to be coordi nated 
anong the users. 


II. The Node - a nultiuser/nultitasking gystem 


Processing at the link level requires real 
time perfornance while higher level tasks are 
less tine constrained. Qn the other hand, the 
link processor serves one packet at a tine 
sequentially while higher level tasks nay run 
concurrently. Also, the progranming activities of 
one user should not influence any other. Thus, a 
SOFTNET node nust be able to support parallel 
tasks besides being able to keep apart the 
current users of the node. For the prototype 
i npl enentation our choice was a dual processor 
(6809) system Mne of the processors are solely 
devoted to link level processing. The second 
processor contains a mul ti tasking FORTH 
interpreter and is shared anong the users. A 
special task - the owner process - interfaces the 
node to the owner's equi pnent which can be 
anything froma dunb terminal to a full grow 
conputer system Inthe latter case the dual 
processor FORTH systemis sinply considered a 
nodem between the owner's system and the 
net vor k. 


IV. Node progranmng exanpl e 


Consider the sinple network given in fig. 2. 
Here four nodes are connected by two-way radio 
paths as indicated by the arcs between the 


nodes. 


Fig. 2. Sanple Netvork 


Suppose a user is located at node A and has the 
Specific task to deliver a large nunber of 
packets to node E, i.e. he wants to establish 

a "virtual" call to E. This can be done in at 
least two ways. The sinplest thing to do is just 
to add a retransmt conmand to all packets as is 
show in fig. 3a). The conmand % takes the next 
synbol as an (one-hop) address and transmts the 
rest of the packet to that address. This goes 
on, dropping one address each tine, until the 
renai ning packet reaches node E were the data 
portion is transferred to the OVKER of the node. 
This procedure nay however consune val uabl e 
packet space, especially when nany internedi ate 


nodes are used. Vé can instead make use of the 
progr anni ng 
78 YO YE OER <data> a) 
%B : WCE." WE" ZC; 
b) 
2B 4C : VCE." OMER' %E ; 
: VCE ." VCE" 9; 
VCE <data> c) 


Fig. 3. Node progranmng 


feature and instruct the internedi ate nodes B and 
C just to pass along the packet to the next node 
in line. This can be done as in fig 3b). Here ve 
define a new function, naned, say, VCE in the 
internedi ate nodes and our ow node. A new 
definition is nade FORTH style starting wth a 

"e " and ending wth a";". The effect of 
executing VCE is to pass on the rest of the 
packet to the next node in line. Also, the 
function places a copy of its nane first in the 
packet for repeated execution in the succeedi ng 
nodes. 
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V. Project status 


Since the advent of the project at Linkdping 
University, a rapidly growng nunber of 
interested radio anateurs have j oi ned the 
discussions. A SOFTNET user group, SUG is being 
forned as a subgroup of AMSAT-SM. Up to date this 
group has received about 1.00 applications for 
nenber shi p. 


Hardware devel opnent has nade consi derabl e 
progress. The Node-conputer board is under 
production and a first shi pnent of 50 kits was 
del ivered in February. Also the PC-layout for the 
LI NK-conputer board is conpleted. The packet- 
radio utilizes a duobi nary direct FSK nodul ati on 
schene wth favourable bandw dth properties. 
Transmssion is synchronous and MM coding is 
used to recover clock infornation. Due to 
probl ens in the design of the radio testing of 
the digital hardware-and software had to be done 
on a cable bound local network. A systemwth up 
to 4 nodes has so far been successfully 
denontrated and has provided useful results for 
further software devel opnent. 


VI. Concl usi ons 


The SOFTNET concept wth its fully 
progrannable nodes wll give the user opportunity 
not only to connunicate, but to conduct 
experi nents in network architecture and network 
protocols. The concept is applicable to all kinds 
of connuni cation networks. An inpl enentati on 
using a local network cable has been successfully 
tested and a UHF-radio broadcast network is under 
construction [2]. 
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regard to the user tarminal or camputer. 
Tt also offloads the frame management 
functions toa an auxiliary processor. 
The asynchronaus dlink to the User 
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ey 


terminal or computer may, at the user's 
SBotion, suppert X-ON/X-OFF or RTS "OTS 
low control procedures, Thera are 
ral designs available ain kit or 
semicrkit form. All are supporting the 
AX.25 protocol and therefore are able ta 
communicate with one another. 


yy 


Has pany 


Cleve t 


Tha AX. 29 prokercgl 
shandar Linkeybevel 
npaceane ae, "Link level" 
cantiral procedures hehwean two 
in direct communication. Some 
chosen to use the 
repeater field in order te 
develop cammunicsa 
FF domain. The use of 
helped improve act 3 
where ait has been introduced, but such 
onperatian has its drawbacks, 
Digipeaters operate solely in the 
RF domain and they transparently repeat 
all data with the proper repeater ID. 
As a result, the ooerational throughput 
15 Cut by more than 30%. Experience has 
diqipeaters ime) be somewhat 
Saou Reena when the local network 
expands. If your station is “luekv" 
to be in close proximity to more 
than one operating digqipeater, YOL may 
find the freguenzy too busy for anything 
but the mast intermittent of 
transmissions. 
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readers to the 
stakians 

qroups 
link-level 

quack. 
beyancd the lacal 
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Local to Sectional Network Access 


The need to communicate beyond the 

1 RF domain will certainiv be well 
ryved by digizveaters as well as by a 
re sophisticated netwark hierarchy. A 
5 of connezted local networks or 
would remove some of the traffic 
from the local sub-networks Ey creating 
geographically smaller networks and 
praviding links on frequencies other 
than the local networks. This aqreatly 
reduces contention for the Local 
channels and imoroves local and inter- 
network throughput 


network 
networks, 
Control 


In order to develop a 
consisting of many local 
procedures will be needed to 


call setup, data transfer and clearing. 


Special management facilities will be 
required to route and service the 
extended network user . The local 
networks will be provi ded with these 
services by special facilities call ed 
"Packet switches”. The switches’ wi 11 
maintain a list of: active stations by 


establishing a camnection to each during 
idle periods. This 1 ist may be accessed 
to check theavailabijity of another 
user. If the desired station is down or 
bus,:, the caller shoul d be abl e to 1] @av 
a "Please call me" message fo r 
user in the switch , This message would 
be automatical lv used by the switch to 
set wp the cal l ance the station becomes 
available. Similarily, if the user is 
not at his normal 3.ocation, forwarding 
information should be left in the switch 


data base and used ito automatically 
reroute incoming calls. 

The switch functions in the local 
network as any other station, but the 
switch should have links going on 
several local and remote”) frequenci es. 
If a station wishes to communicate 
bevond the lacal network, then aconnect 
1s made to a local switch port a. The 
switch then presents a. menu of options 
for the user. This would include a cal 1 
request with routing data _ from the 
switch data base, a call request y based 
on user supplied data, an option to 


leave a “please call me” message or call 
forwarding information. Other features, 
including a mini-message service, could 
be added if local interest warrants. 


Over the inter-network links many 
data can be transmitted. This 
by multiplexing the data using an 

protocol. The CCITT’s 

recommend&i on X.25 specifies procedures 
for this packet level (level three) 
communi Cat i on. Some derivation of this 
would give the amateurs the required 
procedures to operate the net work. 

There also must be some method of inter- 

switch communication, This is needed 


users 
done 
agreeable 


the other 
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to handle special call request 
facilities and switch status 
information, The latter issue is of 


of switches 15 
lf links 


importance if a cluster 
acting a5 a regianal network. 
have been established, the reqicnal 
network may wish to present itself ta 
the outside wor 1d asa homogeneous 
structure with the means to 1 Gacate and 
reroute stations for the cal lina 
station, 


KAZBOE, located in a 
local network, which is apartof the 
Southern New Jersey Section Packet 
network, wishes ta pl ace a. cal 1 go N2DSy 
In the Northern New Jersey Secti on. He 
establishes ai cannectiaonto his local 
switch, then infarms the switch of tis 
desire to contact NEDSY in 
jJrersey. The calling switch has no real 
idea where NEDSY really is within 
Northern New Jersey, but he places the 
Cal.l.. | f the Northern New Jersey 
section net has enough "smarts" to find 
NDS in one of the switch data hases, 
then a call will be routed to the switch 
nearest N2ODSY and the link wwil.l- be 
brought sip. If the 1 i nk is not brought 
up or af N@DSY is busy, the call willbe 


For example, 


cleared with the appropriate cause’ and 
diagnostic code. If the Northern New 
Jersey saction net wark needs more 


routing i ntormat i on from the call er , the 
inter-sectional switch in Northern New 
Jersey will clear the call and may offer 


a iist of local network names to try. 
This latter information may only be 
available if the caller specified in a 
call request facility that such 
information would be desirable in the 
event of a call clearing condition. 
The format and variety of these 


facilities will require some discussion. 


er-Network Access 


The upper 3. evel packet swi tches may 
have a fairly simplej o b af routing 
data, but the volumes that they wi 1] be 
required to handl @ may bel. arqer than a 
radio Club car even a club federation 
could finance. No studies have been 


Northern New 


made iin this area and it requires our 
attention. Sane surplus commercial 
equipment cauld be pressed into service, 
but it must then be operated, housed, 
poawered and maintained. If real-time 
eee aks are to be available, the 
amateur cammunityv will meed significant 
amounts of money and support for the 
network. 

The variety of sectional network 
capabilities must be addressec Bey LT 
packet Levee? roe rahi ey The amateur 
cammunmiby may be bethar of f if Nee 


single link procedures are incorporated 
in A BGle packet Level (level 
standard. This would then el 


wy 4. Cod da oh 


thypee) 


Pminate 


the need for a separate standard and 
Lliplementatian. On the other hand, it 


would require the implementation to he 


more comprehensive. A call could then 
be placed via a "transit metwork". A 


which forwards 
the call. To 
networks of 


network 152 one 
a third party 
inform the transit 


ta As toa 


properly 


rane role, they will require additional 
cantrol informatian f(imtercnmetwor kk 
facilities) in the call request. In the 
eyentk oat an wunsuccesstul ead]. Le 
clearing station must be able to inelude 
the aianformation needed to successfully 


the call 


retry 


ao i LMM ary 


The packet SWitches, imitially 


planned for use in the Northern New 
Jersey Section by the Radio Amateur 
Telecommunicatians Samiety and the 


Club, 
Cig 


will 
Bigar 


Cherryville Amateur Kepeater 
cansist of Digitgal Research 


ale 
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and FADS from Bill Asnby and Son. These 
FADS will perform all dlink overhead 
while the CP/M based Big Hoards will 
perfarcm SWitCcKING and data base 


network will Nave a 
service Area extending from 
Philadelphia, Fennsylvania to Fairfield 
County » Co nee, Ct her ce aups 
interested in extending this are 
welcame. The network alsa ha vYarilety 
of "Rost" computers availa on the 
jatwor k es howe oe A magzar 
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"elect 


the details are being worked out at 
Lime. A lacal chapter of the 


Fiescl Cross has also started to ex 
camputers and radias in 
marmhkain a list ot disaster 


bEheie status. 
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THE EASTNET NETWORK CONTROLLER 


David W. Borden, 
Babe eter 
Sterling, 


Re: 


Abstract 


This paper describes a proposed packet radio 
network control computer running at high packet 
baud rates on the East Coast Amateur Packet 
Network, EASTNET. Principally discussed is the 
digital hardware, but also mentioned is some crude 
RF hardware to accompany the control computer. The 
digital side uses STD bus hardware developed by 
Jon Bloom, KE3Z to begin testing, and eventually 
will use the AMRAD Packet Assembler Disassembler 
(PAD) board running in an S-100 Bus (IEEE-696) 
computer. 


Introduction 


The basis of a real packet radio network is 
the packet switch, which in its’ simplest 
implementation is a two port HDLC I/O board 
running in a microcomputer. 

A Z80 based, STD bus computer has been 
assembled which is capable of sending and 
receiving high speed packets, of at least 48K 
bits/second and possibly 56K bits/second. This 
computer can form the basis of the network 
controller, the smart packet switch. It will 
rs be tested on a wire connecting two such 

evices. 


After the packet switch digital hardware is 
tested, running at some high speed, the required 
RF hardware must be constructe Work will begin 
at 9600 baud, using already proven technology 
designed by Stan Kazmiruk, A. After 
duplicating Stan's system, the hardware can be 
upgraded to faster speeds, at least as fast as the 
digital hardware. 


Following the successful testing of the 
packet switch, the current in-place 1200 baud 
repeaters can be replaced with the new equipment, 
thus increasing the thruput. 


Background 


The essential element of network hardware is 
the digital packet switch. In the crude kludge, a 
packet is received containing multiple repeater 
addresses and the network hardware consists of a 
repeater which accepts the packet, checks it for 
correctness ( CRC correct ), looks for its address 
somewhere in the repeater fields ( up to 8 fields 
currently allowed ), and upon finding its address, 
the packet is repeated, after setting an agreed 
upon "has been repeated bit". 


A slow network can be constructed with this simple 
protocol, but it will not meet the design goal of 
coast to coast packet connectionss. The real 
network controller is a true two port syncronous 
HDLC device that sends and receives packet traffic 
on both ports simultaneously. More to the point of 
this paper, it does it quickly (higher baud rate 
than the local area networks it serves ). To 
achieve our design goal, we require a real IS0 
Level 3 protocol with the software for it 
implemented in our network packet switch. I am 
leaving the protocol fight to others and intend to 
provide fast hardware to implement whatever is 
agreed upon. 


Existing Hardware 


The Vancouver Digital Communication Group 
Terminal Node Controller board is currently being 
used to communicate on the local area networks 
around the country at 1200 baud. It will not go 
much faster on the packet side due to the slow 


Box 


AMRA 


Se 
2335 
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clock speed, the noisy 74L8138 I/O decoder and 
slow 2708 EPROMs. Bill Ashby has been trying to 
get it to function at 9600 baud and has failed. 


The Tucson Amateur Packet Radio (TAPR) 
terminal node controller may go higher speeds than 
1200 baud by not using the on board modem and 
cranking up the clock speed. However, Tom Clark, 
W3IWI ks the interrupt structure may be overrun 


at 9600 baud. This represents anunknown at this 
point. There eepcare no way to go 48K bit/second 
or greater speed, 


The Bill Ashby terminal node controller has 
been tested at 9600 baud and works well. It 
probably will not go faster than that, but Bill is 
testing 10% 


The AMRAD Packet Assembler Disassembler (PAD) 
board, designed by Terry Fox, WB4JFI, exists only 
as a prototype board currently with plans for 
making printed circuit boards sometime in the 
future. It is not available for hign speed 
experimentation, but will be capable of the higher 
speeds once it is in production. 


An STD bus packet radio repeater exists and 
can possibly be used for high speed work. AMRAD is 
proceeding along these lines. The repeater is 
currently working and requires little modification 
to be used in network service. 


STD Blue Box Description 


The STD bus was developed commercially by 
PRO-LOG, and is supported by over 30 manufacturers 
including MOSTEK. AMRAD managed to obtain some 
STD computers ( referred to as the "Blue Box" ) at 
a reasonable price. The computers used the MOSTEK 
MDX-CPU2 CPU card, a Z8C microprocessor with on 
board Counter/Timer (CTC) circuit. and RAM/ROM 
sockets for 11K of memor The heart of’ the 
packet work is accomplished with the MDX-SIO 
Serial I/O module, a serial board based on the 280 
SIO controller. The STD Bus is not the integral 
part of this system, the SIO is. This hardware 
could have been placed on the S-100 Bus just as 
simply. In fact, the designer of this packet 
project (Jon Bloom, KE3Z) has done just that,, 
using the California Computer systems CPU card 
containing an SIO and CTC, however no details of 
that work are available and the CPU card price is 
excessive. 


The problem with using a Z80 SIO is that it 
does not do digital phase lock loop (DPLL) 
recovery of the data derived clock, nor does it do 
NRZI encoding. Jon solved this problem 'by 
building a state machine (prom and latch!) for 
receive and another for transmit to perform these 
functions. Details of this design ( what is in the 
proms and schematic ) is available from the AMRAD 
Corresponding Secretary. Using this hardware!, 
repeater software was written to use this box as a 
digital repeater. This repeater functions well at 
1200 baud while connected to a conventional Bell 
Standard 202 modem. This box thus forms the basis 
of the big experiment. 


Proposed Experimentation with Digital Hardware 


The proposed experinnentation will begin with 
the construction o:£ a second STD box to hook to 
the first with a standard RS232 wire cable, The 
"umpers on the SIO cards are first set at 1200 

aud. The current software repeats, but is 
modular. A short bit of additional software can 
be easily written to send a packet from Box 1 to 
Box 2 ( running the repeater software ). Box 


wll repeat the packet and send it back to Box 1, 
which will receive it and display it on the system 
console. Then, the jumpers are moved in both boxes 
to run successively higher speeds until a packet 
is no longer returned. 


Jon's estimate is that 48 K bits/second is 
going to work fine, but 56K bits/second may prove 
a problem. 


Another possible upgrade could be made to the 
STD hardware with a little effort. The SIO board 
and state machine board could both be replaced 
with a 8530 Serial Communications Controller (SCC) 
board. This is the same chip used on the AMRAD PAD 
board. A kludge board has been purchased for this 
urpose. This makes good sense as software could 
Be easily developed in the STD box and transferred 
to the PAD board with few changes. This would be 
actually easy as ae few Seugae chips should be 
required to put the 8530 on the STD bus. No state 
machines would be required as the 8530, like the 
8273 and 1933, performs the required DPLL and NRZI 
functions. 


Another additional benefit could be derived 
by keeping the old SIO board around. Two 
independent channels of HDLC could be run, thus 
achieving our true network control easily. The 
only drawback is the required development time as 
the SIO-State Machine board works now. 


Assume for the sake of discussion that 48K 
bits/second works properly. Then, RF boxes is the 
next logical step. The jumpers can be returned to 
9600 baud and proceed to the next step. 
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Proposed Experimentation with RE Hardware 


Several years ago, Stan Kazmiruk, VE3JBA, 
published the designs for the Ottawa Digipeater. 
This hardware repeated 9600 baud packets using a 
transmitted signal with modulation of +/- 2.5 KHz 
which proved to be 12 to 14 KHz wide at 6 db down 
and not over 22 KHz wide at 30 db down. The 
design centered around transmitter and receiver 
modules made by VHF Engineering, a company no 
longer making these modules. Stan mentioned that 
Hamtronics was making similar modules that should 
work. AMRAD has a number of these modules and are 
now Beets them for this ae speed work. They 
ep pear to be capable of 4800 baud as they are 
shipped and perhaps greater by disconnecting some 
crystal filter stages. The principal is clear and 
is receiving attention in New Jersey also ( Bill 
Ashby's gang are going 9600 baud now ), Transmit 
is done by direct FSK of the transmitter, and 

lace the demodulator at the IF (10.7MHz or 
TSSKHz). Faster speeds are certainly possible. 
Video techniques should get us to 56K Hite /eecond. 


Conclusion 


The low speed 1200 baud packet work going on 
all over the country now is fine for local area 
work. Higher speeds are required for networking. 
The hardware/software needed for networking need 
not be copied by a causual observer as the network 
packer switch is much more complicated than a TAPR 

oard and not as many are required. We should set 
our sights at going as high a speed as our allowed 
100KHz bandwidth will allow. We should use 220MHz 
for this work as it is relatively unused over the 
majority of the country and needs to be saved from 
the commercial land mobile radio service. 


HF PACKETS: 
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With the increasing Packet Radio 
activity and need for long-haul linking 
between Local Area Networks (LANS), a 
number of experiments are being conducted 
on the viability of packet radio on the HF 
bands. The simplest approach is direct 
application of the existing 202 standard 
modem tones on HF using 300 baud. Although 
successful links have been demonstrated 
over long distances under ideal conditions, 
the performance degrades rapidly under 
typical interference conditions. The 
throughput falls to zero in the presence of 


interfering signals in the wide bandwidth 
of the Bell 202 standard modem. This paper 
will introduce two experiments with 
alternative modems and will briefly 


describe the experimental HF to VHF gateway 
currently operational in the Washington DC 
area, 

"The Packet Adaptive Modem" 

An effort headed by Paul Rinaldo W4RI 
is aimed at development of a packet 
adaptive modem (PAM) which will be able to 
dynamically adapt to band conditions. The 
PAMs would use the re-try count as a figure 


of merit to adjust the baudrate and 
bandwidth up or down according to a 
standard algorithm. The PAM will use 
minimum shift keying (MSK) which minimizes 
bandwidth while taking advantage of 
synchronus detection. Two prototype PAM 
boards have been constructed and will be 
tested by W4RI and WB4JFI. A special 
temporary authority from the FCC will be 
required to operate at baud rates greater 


than 300 baud. Initial tests will probably 
use 600 Hz shift at 600 baud. 


"Bell 103 Standard on HF" 


The approach used at this station is 
an adaptation of the existing radioteletype 
(RTTY) and phone line technology using a 
Significantly narrower bandwidth than the 
202% A plot of comparitive bandwidths 
between the _ Bell 202, 103 and a typical 
narroband RTTY demodulator are shown in 
figure 1 which’ suggest the significant 
improvement in interference rejection of 
the narrow-band demodulators. HF RTITY has 
long been characterized by very narrow 
filters to optimize reception in the 
cluttered HF spectrum. Unfortunately most 
of these HF RTTY modems have a keying rate 
filter matched to the relatively slow baud 
rates between 45 and 75 baud which prevents 
their use at the preferred maximum HF 
packet rate of 300 baud. 
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Figure 1.  Bandnass characteristics of several 
modems showing the suscentibilitv of the Bell ?? 
modem to interference on an HF channel. 


Bell 103 
however, has a frequency 

approximates the narrow 
HF demodulator while 

baud. The 
to use the 
radio is t 0 


The readily available 
ORIGINATE modem, 
and shift which 
bandwidth of a good 
having a design speed of 300 
only modification required 
ORIGINATE modem on _- packet 
modify the transmit tones from 1070/1270 
Hz to 2025/2225 Hz to match the receive 
tones for transceive operation. If 
receiver incremental tunning (RIT) is 
available on the transceiver, this 
modification is not necessarily required. 
Although the ORIGINATE modem has a 
bandpass filter matched to the 200 Hz 
shift  comparablel te the filter used for 
170 Hz shift HF RITF', its performance may 
not be as good as some of the best RITY 
demodulators which use post-detection 
circuits Co GOrrecl. for selective fading 
and frequency drift, These GOrrect. rons 
are not necessary in the phone line modem 
and are therefore not included. 


Concurrently with my ORIGINATE modem 


conversion, several stations with  TAPIR 
TNCs were working toward a 200 Hz shift 
modification f0r the onboard TAPR' PLL 
modem. About mid February, these designs 
merged and 300 baud packet activity wi.th 
206) Hz Sherr commenced on the new IO Mhz 
band. 


“Present HF Packet Activity" 


For the 
stations WB4APR in 
Chicago, and WORPK in 
exchanged packets under a 
Condi £Lons.. At this early 
station sends periodic beacon packets to 
allow frequency netting and propogation 
determination PLLOLr pea) attempts at 
establishing a connection. On this_ band, 
WB4APR and W9TD have experienced good 
packet conditions throughout the full test 
period of 10 AM to 10 PM local time. A 
large portion of the time, 90 percent of 
the packets are received without error or 
re-tries. Presently there is not a problem 
with interference on the relatively new 10 
Mhz band. The frequency used for packet 


past several weekends, three 
Maryland, W9TD in 
Towa have regularly 
variety of 
stage, each 


activity is 10.147 Mhz which is slightly 
above the center of RTITY activity around 
10.140 Mhz. The key jaye) successful 
connectivity is frequency Stability and 
accuracy « For this reason, crystal 


controlled operation is being contemplated 
for serious link operation. 


"The WB4APR-5 HF Gateway" 


As a preliminary demonstration of the 
capability to extend local area networks 
(LANs) via HF, an experimental gateway to 
the Washington DC area VHF packet radio net 
was constructed as shown in figure 2. Two 
VADCG terminal node controllers (TNCs) are 


connected back-to-back through a VIC-20 
gateway. The TNCs are available on their 
respective channels for connects in the 


Upon detecting a connection 
Gateway program 


usual manner. 
on either channel, the 
running in the VIC-20 acknowledges the 
connection with a brief prompt. The user 
may then select a number of options’ to 
assist him in establishing a connection. 


VIC-e0 
GATT WAY CONTROLLER 


Figure 2. Tne WRYAPR exsmerimental HF = ratewny 
{nto the Washineton DC areca VHF packet radio net 
implemented with back-to-back TNCts and a VIC-°0, 


"Gateway Program" 


Although the purpose o f the 


gateway is to provide transparent data 
connectivity from one channel to the 
other, in the absence of a Level III 
protocol, this experimental gateway offers 
several options as shown in figure 3. In 
addition to the connect and disconnect 
commands it offers a list of users 
available on either channel. In keeping 
with existing TNCs, it allows the user to 


monitor packet activity on the other 
channel in an unconnected mode; a variable 


beacon capability may be selected to 
assist in further HF experiments; and 
lastly, it provides a message capability 
to the system operator from either 
channel. 


kk AMRAD HF PACKET GATEWAY ** 
-- COMMANDS ----------------- 


HELP (or ?) 

USERS HF (or VHF) 

LOG (shows log of usage) 
INFO (describes system) 
BEACON XX (every XX seconds) 
MONITOR (unconnected mode) 
CONNECT W4XYZ (to sta W4XyYZ) 
DISCONNECT 

GOODBYE (or BYE) 


Figure 3. Commands available to the gate- 
way user via the VIC-20 gateway controller. 


"Message Store-and-Forward" 

ike becomes obvious that the 
gateway controller could serve both 
networks with a store and foreward nessage 


capability. Tom Clark W3IWI has suggested 
that the message store-and-forward node 
controller is the next logical step in 


local area 


improving the connectivity of 
networks in the absence of a level III 
protocol. To this end, Terry Fox WB4JFI 


is assembling a S-100 computer system to 
run readily available CB‘*BS software on the 


local VHF packet net. As the existing 
gateway software is improved In the 
future, the HF gateway and CBBS system 


will hopefully be integrated to take 
advantage of common hardware. 


"Future Gateway Hardware" 


The obviously ineffecient 
back-to-back method of implementing a 
gateway will be significnatly improved by 
the Packet Assembler-—Disassembler (PAD) 
currently under development by Terry Fox. 
This S-100 board will be a_ conplete stand 
alone packet board which features two 
Packet serial devices and sufficient RAM 
and ROM to support the gateway and future 
level Hea software. This board is 
currently in the prototype stage. 
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Annapolis, MD 21402 
The idea of a digital packet radio BY proper orientation of these interests, 
network linking the Fast Coast was the growth of packet radio can proceed 
envisioned in the late LTO" Ss when the smoothly to faster data rates and more 
Department of Communications in Canada and sophisticated network capability while 
later the Federal Communications Commission retaining lower level gateways to casual 
in the US authorized the transmission of users. This appeal to the entry level user 
digit ad data over amateur radio must be maintained in order for packet 
frequencies. Today, EASTNET is a reality radio. to. Elourish. 
with relay sites becoming operational in 
Washington DC, Maryland, New Jersey, New PHASE. -I 
York, Connecticut, and “Boston. By 19854 
connectivity from Boston to Norfolk will be Using the level II protocol AX.25% 
established. This paper will discuss the local area networks (LAN's) have flourished 
present status of EASTNET and will propose in several of the major population centers. 
an orderly plan for development of a more The extension of these LAN'sS across 
sophisticated, higher data rate system. their local boundaries was made 
Repeater Siting considerations and possible by an extension ’ 
frequency planning will be addressed. of the level 11 Tose ies eed 
protocol AX.25 
Background KD2S rs] 
Developing the: “concept f MASS : 
of an East Coast packet / 
radio network has been = an § 
evolutionary process. As an Pe ee, tg ee Q il see 
all volunteer effort, there i a bs 
are as many ideas and N ¥. { CONN. i ps. 
experiments as there are F ' 
participants. Some individ- ' ' RT 
uals have been working ) ; WIAW t 
toward high speed/high ‘. : : 
reliability hardware, and = 
sone have been working for i WALL) I@) 
ori-<the=shelt solutions f ™ @ Py 
while others poured their / Ps < 
efforts into the software / ~, | ge 
which would tie these 4 \ ad to allow an 
diverse elements together. 2 : extendable 
The EASTNET that we have { KAIQ Pp repeater ad- 
today is the Legicas \ @ 0? dress: iietd 
extension of these pockets ‘ containing 
Of. activity, oe as many as 8 
ie repeaters. 
‘ Extending EASTNET by taking advantage 
O : Of ‘this ‘explicit routing: capabsality Ls 
PENN Cao what is currently happening and is 
° , what we should call PHASE I. PHASE I 
haere has the advantage of expediency as it 
eee i ia ee N J. implements a degree of network 
WallapRe 1 § connectivity in the existing level II 
M D t Pretec. With this minimum level 
. : connectivity, the major players in the 
ie | development of the level III NETWORK 
. "ad . layer protocol can begin to communi-~ 
ni : cate using the channel to enhance 
ae IRI ; further efforts. The disadvan- tage 
ys : is that it compromises the defini- 
i 
] 
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rapidly saturate the existing net. 


PHASE IT 
The amount of time that will be 
required to define and develop a level III 
NETWORK layer protocol will be significant 


but will allow a PHASE [I improvement in 
the EASTNET link hardware. The goal under 
PHASE II will be to move packet’ radio 
activity to a significantly higher baudrate 
in preparation LORS the eventual 
implementation of the level III NETWORK 
protocol under PHASE III. Also under PHASE 
nie ee integration of gateways to other 
channels such as KF and satellite longhaul 
links will be developed. The hardware will 
be improved, frequencies’ established, and 
permanent repeater sites located. 


PHASE III 


In PHASE III, ~ the level III 
NETWORK layer’ protocol will be implemented 
within the PHASE II high reliability link 
hardware, with gatewaysa s necessary to 
match the topology of the network. 


Frequency Considerations 


packet activity is 
currently centered on two meters because of 
the overwhelming popularity of this VHF 
frequency band. The early use of this band 
for packet radio has’~ had the advantage of 


The majority of 


attracting new users because of the 
availability of equipment and ease of 
integration into existing operation. The 
explosive growth of packet radio, however, 
Will quickly saturate the available 
frequencies in this very active band _ and 


require new frequencies to be identified. 


The 220 Mhz Band 


area for expansion of 
This 


The ideal 
packet radio is on the 220 Mhz band. 
band is”7~ relatively under used because 
historically there has not been as much 
commercial equipment available as there has 
been for two meters and 450 Mhz. In fact, 
the under’ utilization of 220 Mhz _ has made 
it a target for several attempts by commer- 
cial interests to obtain the spectrum space 


from the FCC. Not only is the spectrum 
space presently available for wideband 
packet radio expansion, but if the present 


rate of packet radio expansion continues 
and a_- specific band segment on 220 Mhz can 
be dedicated to packet radio. use, the 
amateur radio community might finally be 
able to prove conclusively to the FCC the 
tremendous utility of this band. 


Discussions with Paul Rinaldo W4RI at 
ARRL and the local repeater coordinating 
committee have suggested the following band 
plan for packet radio_ which would be 
compatible with the existing ARRL plan. 


220635 22 Led 

220.65 221.03 

220.75 »100 Khz 221.05 720 Khz 
220.85 eee 

220<95 221.19 


The key elements of this proposal are _ the 
allocationo f 220.5 to 221 Mhz = for 
experimental use a.nd the overlap of wus and 
Canadian  privilege:3 which allow 100 Khz 
bandwidths in that segment. Five 100 Khz 
channels would be established, Narrow-band 
20 Khz activity could go immediately above 
221 Mhz where wideband modulation is not 
permitted for the Canadians. Since’ the 
current allocation of the 221.0 to 222.0 
Mhz segment of the band is’ for link and 
control frequencies, application for 
narrow-band packet radio use must be made 
through the local frequency coordinating 
bodies. If enough applications are filed 
fol narrow-band 20 Khz packet radio 
frequencies on the low end immediately 
above 221.0 Mhz, eventually maybe a 200 Khz 
segmentfor ten 20 Khz channels could be 
standardized. Packet radio groups 
contemplating experimenting with 9600 baud 
on 220 Mhz should request coordination of 
these frequencies not currently in use 
beginning at 221.0 Mhz and up in their 
local area. Allocation of the 5 wideband 
channels should be addressed at a national 
level , recognizing that hardware will take 
longer to develop, 


Backbone and Gateways 


As level III NETWORK layer 
software becomes available, a single 
network controller will be defined f'or each 
community. This controller will be the 
Data Communication Equipment (DCE) to a11 
Data Terminal Equipment (PTE) in the [Local 
Area Network (LAN). Any rumber of links or 
gateways to other networks, can be logically 
conmnecteda s DTE’so r thecontroller can 
have’ transparent connectivity to nearby 
noc'es or long haul backbores. Tne details 


of this connectivity will be addressed in 
the level III standard, The EASTNET 
repeater sites during FHASE I will be 
upgraded to 220 Mhz9600 baud capability 
while retaining the two meter gateway 
frequencies of 145,010 Mhz for local use 
and access -« By the time level III is 
ready, 56 Kbaud widebandchannels will be 


implemented which can handle the backbone 
traffic of both the two meter low speed and 
22C Mhz high speed local channels. 


Rereater Site Selection 


The goal of PHASE I is to locate good, 
permanent link sites with optimum spacing 
to minimize the number of repeaters 
required in the backbone’ system. With 
thcusands of two meter repeaters across the 
cocntry there is < wealth of experience 


with the reliable communications’ range of 
two meter voice operation, This 
experience, however, is based on the usual 
motile/fixed station-to-repeater path and 
does not include the more advantageous 
refpeater-to-repeater path to be used in 
optimum backbone repeater siting. For the 


Elk Neck repeater site, the Washington DC 
repeateri s barely detectable at ground 
level using a good mobile antenna, whereas 
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100 feet up the tower 
received on a walkie-talkie. 


the repeater is well 
The following 


paragraphs help quantify the expected 
performance of a repeater’ site from data 
obtained using the Washington DC repeater 


and a portable packet station consisting of 
an ICOM IC-2AT, VADCG TNC, and VADIC 202 


modem. 
Path Loss 
Figure I shows the typical 
microwave line of sight plot using an 


equivalent earth radius factor of 4/3 for 


the Washington to Elk Neck path. Clearly, 
an absolute line of site path is not 
necessary at 145 Mhz for reliable 
reception. 

2 


Washington DC 


hk 


Neer 


Line-of-site path over flat earth and 
N/3 eouivalent earth curvature. Total nath = lenreth 
of 75 miles. 


TMipure 1. 


A plot of tropospheric path loss vs. 
distance from the ARRL VHF Manual is 
reproduced as figure 2 and shows a definate 
flattening of the curve at 200 db from a 
range of 120 to 200 miles. Although these 
ranges can be easily operated with weak 
signal equipment such as CW and SSB, they 
cannot give the 20db_ signal-to-noise (S/N) 
ratio necessary for the relatively wideband 
AFSK FM modulation techniques’ currently 
employed using the typical omni-directional 
medium gain antenna of a packet repeater. 


(db) PATH LOS? 


220 PPAC M7. 
aes 
200 . 
TMH? 
180 
160 « 
140' 
MILES 
120 
0 100 200 300 
Fipure ?, Trorosnheric nath loss vs. distance for 


VIF amateur frequencies for 99 rercent reltability. 
(reprinted from the Radio Amateur's VHF Manual) 


Receive Margins 


Using the portable packet station 
at several distances from the Washington 
repeater, packet receive margins were taken 
with a step attenuator and normalized to a 
zero db gain receive system consisting of 
the IC-2AT receiver. These receive margins 
plotted in figure 3, can be used to predict 
packet performance at a_ particular. site 
relative to the 40 watt ERP transmitted 
signal at an antenna height of 200 feet. 
To use the plot, simply subtract feedline 
loss, andadd antenna gain and antenna 
height gain from the nomogram in the VHF 
Manual. Antenna height gain on paths of 
about 55 miles is roughly Odb at 30 feet 
and increases by 4 db for each doubling in 
height. Although these measurements’ are 
only accurate to 3 db or so, they do show 
that repeater separations on the order of 
50 to 60 miles are achievable with nominal 
sites and equipment. 


Mirure 3. Receive marrin from 
HO W ERP tranamitter at enn fr. 
referenced to 0 db at receiver 
(IC-?PAT) 


db 


30 


@nctual 


predicted 


~10 


miles 19 ?2n 30 


The plot can be- used for any other 
transmitter height and ERP by appropriate 
corrections. The reliable path between two 
40 Watt ERP repeaters at 100 feet with 6 db 
gain antennas, 2 db line loss, and 7 db 
receive margins should be about 50 miles. 
The same stations at 60 feet should be no 
further than 40 miles apart. Mountain top 


sites have an additional advantage which 
can add as much as 35 miles’ per 1000 feet 
of altitude over average intermediate 


A direct comparison of this data 
to the calculations illustrated in the VHF 
Manual suggests using 1 db for the noise 
figure, 12 Khz bandwidth for’ the receiver, 
and a signal to noise requirement of 11 db. 
Because of the FM improvement factor, an 11 


terrain. 


db carrier to noise ratio results in 
approximately an 18db_ signal to. noise 
ratio for the 202 modem. Using these 


path margins using 
support the 


assumptions, calculated 
the VHF Manual _ procedures 
empirical data. 
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EASTNET Site Summaries 


Each of the following summaries is the 
best information available at the time of 
this writing (mid March 84). The order is 
roughly south, EO: north. 

Hampton, Virginia 

Bill 
his repeater in 


Holmes W4UMC has operated 
the Hampton Virginia area 
for over a year, Being 140 miles from the 
Washington DC repeater, he will probably be 
linked via Richmond and Fredricksburg. 


Waynesboro, Virginia 


Fred KF4DQ speaks for a group of 


operators interested in linking down the 
Shenandoah Valley from the Washington DC 
repeater. They have the Blue Ridge 
mountains to cross, but may be able to use 


that to advantage as altitudes of 3000 feet 
might be possible. 


Washington DC 


The AMRAD WB4JFI-5 repeater has 
been in operation since 1982 on the AMRAD 
voice repeater but was moved to its present 
site on the channel 9 TV tower in October 
1983 replacing the WB5MMB simplex repeater 
in Vienna, The tower is on the highest 
ground in the District at 400 feet but 
suffers from a very high RF environment. 
It was moved to 145.010 Mhz in January 1984 
coincident with the decision toe .burn=in 
that frequency for packet use on the east 
Coast. It uses a VADCG board and runs 15 
watts through a LO. mich. cavity. -21nto -san 
unknown abandoned VHF high band antenna 
about 200 feet up the tower. 


Elk Neck, Maryland 


The WB4APR-6 repeater has been in 


operation since February 84 but was moved 
to its present site on a 120: Loot state 
f orrestry tower at 285 foot ground 
elevation on 8 March 84. The site has 40 
miles of its 75 mile path to Washington 
over the Chesapeake Bay. It has good 
visibility into the Wilmington and possibly 
Philadelphia area with a= slight shadow 
around Iron Mountain. The repeater is a 


good beacon, but suffers from poor receiver 
sensitivity and an undetermined transmit 
tone anomoly which degrades long packets. 


Replacement hardware is under construction 
which should allow connectivity with the 
Washington repeater. 
Philadelphia, Pennsylvania 
No optimum site has been 
1dentified although the TelCo. Pioneer 
Amateur Radio Club has expressed interest 


and has a downtown building top location. 


Steve Robinson W2FPY reports a possible 
site on -the 125 foot “Burlangton) Municipal 
tower on aground level of 85 feet; but 
this area is about 15 miles further away 
from Elk Neck and signal strength is low. 


Warren Township, New Jersey 


Phil Karnes KA9Q has been 
beaconing on 145.01 Mhz Since February 
using his TAPR TNC. He is located on a 
very good hill with excellent southern 
WieSa Ba. Lay: He has possible access to the 
EGD OL the hill (500 feet) and a tower 
which would improve his shot to the north. 


He reports good connectivity with W2LQQ in 
Warwick NY. A possible conflict is RFI to 
his satellite activities. 


Warwick New York 


Rip W2LQQ has also been beaconing 
on L45,0L - Miz sang his: TAPR: .TNC and 


reports favorable connectivity down to 
KA9Q. He is presently using his OSCAR 
array and would also have to solve the RFI 


problem with his satellite activity. 
Stamford Connecticut 


Ed Kalin KIIRT is interested in 
joining EASTNET and possibly serving as the 
link site towards Newington. Has: visibilay 
over to Long Island is also favorable. 
Path lengths to Warwick and Newington are 
reasonable if a suitable high altitude site 
can be located. 

Newington, Connecticut 

As the national headquarters of 
the ARRL, the WIAW packet repeater is a key 
Site in EASTNET. The repeater has been on 
the air Since January 1984 using a VADCG 
board at the ARRL station. This site is 
not optimum and will hopefully be moved to 
a higher location possibly at 1000 feet to 
enhance EASTNET connectivity. Paul Rinaldo 
W4RI is the point of contact at the ARRL. 


Rhode Island 


A site located in northwest Rhode 
Island or south central Massachusetts would 
have reasonable 50 mile paths to link 
Newington to Boston. No activity reported. 


Boston Massachusetts 


The present packet repeater in 
the Boston area is KD2S in Lowell about 28 
miles northwest of downtown. This repeater 
coupled with a good site southwest of the 
city would help in extending EASTNET down 
toward Newington. Efforts to obtain a good 
mountain top location could extend coverage 
throughout the state. 


EASTNET Coordination NET 


To facilitate inter-site communication 
for the further development of EASTNET, an 
AMRAD Packet Radio Users Group Net will be 
maintained at 2200 EST on 3855 Khz every 
Tuesday evening immediately after the 
regular AMSAT net. Participants in EASTNET 
are encouraged to check in for the regular 
dissimination of EASTNET and general packet 
radio information. 
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The Racing Problem: A Packet Solution 


Robert E. 


Bruninga 


6103 Hillmeade Rd. 


Bowie, 


Background 


Last June several members of AMRAD 
participated in the Old Dominion horse 
ride and 100 mile endurance run near Front 
Royal Virginia by providing mobile and 
emergency communications. A dozen or so 
checkpoints were manned by radio amateurs 
as well as shotgun riders with each of the 
key event and emergency personnel to 
provide VHF communication throughout’ the 
several county area of rural roads-~ and 
1500 foot mountains. A portable repeater 
was constructed out of two Icom 2AT 
walkie-talkies and battery powered 
throughout the weekend event. This was 
only the beginning of the excitement 
involved in designing a better way to do 
it next year, In fact, our primary 
interest as noted in Dave Borden's AMRAD 
Newsletter Packet column of July 83. was 
the desire to link a system of computers 
on packet radio to handle the data on the 
over one hundred horses, riders and 
runners so that information would be 
readily available at key points: fer 
emergency purposes. This paper will 
describe a distributed data base system 
implemented with Commodore 64 and VIC-20 
Computers linked via amateur packet radio. 


Data Reporting 


where all the horses, runners and 
emergency personnel are located is’ the 
Single key to rapid response in 
emergencies. Keeping the time of arrival 
and status of all race entries at each 
checkpoint in a large array space would 
allow easy manipulation of the data to 
serve a variety of needs. Since series of 
numbers are already assigned to the 100 
and 50 mile horses and runners, a series 
of numbers assigned to key personnel and 
emergency services would allow them to be 
tracked in the same data system throughout 
the course. A single reporting format can 
be used for any horse, person, or asset of 
the form as shown in figure 4. 


Knowing 


NUMBER, TIME, LOCATION, DATA 


reports may be used directly to 
N-by-L array of time and status 


These 
update an 


for every unit in the event. Here, N is 
the number of persons and horses andUL is 
the number of reporting locations. 
Actually two arrays with the first one 
recording the time of arrival and the 
second one containing a coded status or 
departure time would hold _ the entire 


status and historical file of the event. 


Md. 


20715 


Data Fields 
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BY coding the checkpoint names and 
status, a very short fixed length string 
may be used for transmitting this data 
across the data channel. With a three 
digit number, three digit time, Single 
character checkpoint and status key, this 
string is only 8 characters’ long. The 
format of figure 1 has been designed not 


only to be as short as possible but also 


to require a minimum of processing 
overhead. 
NNN HM S L D 
| Co—Data 
| Location 

Time 

Number ID 
Figure 1. The format of a single race 
item report Consisting of 8. ASCII 
characters. 
The generality of this report is 
accomplished by assigning numbers’ to 
everyone and everything in several 
compatible number series. For the Old 
Dominion Ride and Endurance run two such 
number series have already been used. 


They are the 100 series and 500 series for 


the one hundred and fifty mile entries 
respectively. Using these numbers asa 
starting point and making some judgments 
on potential group sizes, the numbering 
scheme shown in figure 2 is suggested. 

1-99 - Ride, Radio and emerge pers 

100's = One hundred mile entries 

200's » Runners 

300’s = Runners 

400's @ Cavalry 

500's = Fifty mile entries 
PUGure:. | 2. Number series to uniquely 


identify all race entries and race assets. 


each of these items at 
The locations 


Associated with 
any one time is a location. 
might be gates or checkpoints, or they 
might take on other meanings as_ well. 
Since the data packet going over the radio 
channel needs to be as_ short as possible, 
these location identifiers should be keyed 


into a Single character roriiat. This 
allows up to 91 keys using the ASC and 
CHRS functions over the range 35 to 126. 


is also compressed 
one each for 
Some keys for 

route and 


in this way, the time 
into three ASCII characters, 
hours, minutes and seconds. 

locations along the trail 
elsewhere are shown in figure 3. 


ASC CHECKPOINT ASC LOCATION 

35 - 4-H camp 55 = Broadcast msg 
36 - Lands Run 56 - Front Royal 
37 - Bentonville Br oy = Luray 

38 - McCoys Ford 58 - Detrick 

39: “#1615 <sp li 59 = King Crossing 
40 - Yates 60 - Pala’s 

41 - Bixlers Br 61 - Repeaters 

42 - Woodstock Gap 62 - Mobile 

43 - 50 Finish 63 - Food 

44 = Edenton Gap 64 - Gas 

45 s Hickory Lane 65 - Searching 

46 - Virginias 66 = Vets 

47 = Seamens 67 = Unavailable 


48 - Picket Springs 68 = Gone home 
49 = Shermans Gap 

S01 =. COS: Spa 

51 = MeCoys Ford 

52 - Lands Run 

53: > 100 “Finish 


Figure 3. A table of suggested location 
identifiers by their ASCII equivalent 
codeSe 


The single character keyfields allow some 
91 different locations and status 
indicators to be represented. Several 
suggested data keys which can serve horses, 
runners and VIP's alike are as follows: 


I - IN Ox = OUT 

H - HEADED FOR Lo DOST 

M - MESSAGE FOR Vos VET (NEEDED 

Ss. = SCRATCHED P - PULLED 

C - CREW NEEDED D - DOCTOR NEEDED 
F = FURRIER NEEDED E = OUT TO LUNCH 
ETC 


Packet Radio Data Distribution 


Recognizing that the most important 
real time data on any item in the data 
base is only the last reported status, the 
organization of the data network asa 
distributed system could make it much more 


survivable in an amateur/portable 
environment. Also the ‘KISS. ‘principle 
(Keep it Simple, Stupid) could be followed 
more closely. Under this concept, there 


is no central computer and all the field 
display computers need to maintain only 
the last known status on any single item 
in the data base. To minimize data 
channel load yet provide for full refresh 
of the data at the display terminals, a 


scheduler in each computer would 
periodically retransmit all data entries 
for which it was responsible. Because of 
the one-to-many distribution ot the 


updates to all other display terminals, 
the packets will be transmitted and 
received in the packet monitor mode error 
free, but without acknowledgment. Sending 
one of these refresh packets every number 
of seconds would assure complete data base 
refresh every few minutes or so. With 8 
characters per data item, a concatonated 
combination of eight such items per line 
would make a nice size packet as shown in 
figure 4. 


#uTNNNHMSLONNNHMSLD ee eee e NNNHMSLD 


——_— p—— 

E& #1 item #2 item #8 
Transmitting station identifier 
Update identifier 


Figure 4. A single packet frame 
consisting of eight individual item 
reports. 

This Single string format allows 


Simple Basic input commands to be used to 
input the complete string at the display 
terminals in one operation and minimize 
packet overhead. The line can be verified 
prior to array update by testing for the 
update identifier and fixed length of 67 
characters. If a display terminal crashed 
or lost its data, it could be allowed to 
slowly rebuild its data or it could be 
completely updated by any other computer 
in less than 30 seconds on a dedicated 
basis at the 1200 baud channel capacity. 


Display Processing 


Once received, the updates are entered 
into a string array of the form 
SS(N)=HMSLD where N is the item number 
(which may have to be hashed for effecient 
use of array space if multiple item number 
series are used) and HMS, L and D are 
time, location and data keys respectively. 
The individual display terminals then can 
be programmed in a variety of ways to 
provide querie/response information on the 
latest Status. Several possible screen 
display Lormats such as the following 
could be implemented: 


locations of VIP's and Emergency pers 
Top 20 Horses 

Last 20 Horses 

Horses at location X 

Status of Horse Y 

Horses departed location xX 

Missing horses 

ELC 


eb ee Oe OE Oe 


The possibilities are endless and free to 
the imagination of the display terminal 
programmer. This flexibility is necessary 
due to the variety of computers and screen 
Size formats which will be used. 


Notice that nothing prevents a Single 
computer from building the complete set of 
N-by-L arrays since all of the data will 
have been transmitted on the channel. In 
fact, 16K or larger and Disk based systems 
should be programmed with this capability. 
Also note that as checkpoints are 
completed and all race entries have passed 
through a particular point, there is no 
further requirement for packet refresh 
from that station. That packet station 
can then be moved to a later checkpoint 
for reuse. 


Data_Channel Activity 


As the flow of the race progresses, 
data channel activity will tend to. migrate 
from station to station as shown in figure 
5. For a race of 160 entries, the starting 
point station will initially be responsible 
for all 160 reports, which, in groups of 8 
corresponds to 20 packets. If one packet 
is transmitted every 12 seconds, a complete 
update is provided every 4 minutes. This 
cycle will continue until the lead horse 
arrives at gate two . As reports are 
initiated from that station, station one at 
the starting point will see the reported 
location field change and stop refreshing 
that entry on a one-for-one basis with 
reports it hears from the new reporting 
station: This is very simple since each 
station uses the location field to identify 
its own reports which it is responsible for 
updating. In this manner it can be seen 
that there will always be a nominal 20 


packets per period being transmitted and 
that the peak load will move asa bell 
curve distribution from station to station 


as the race progresses. There will also be 
a nominal background level of packets from 
other stations reporting the movement of 
VIP'S and other status throughout the 


course. 


Channel activity at 
race start time T=0O 


4 
2 
9 4-----f===== Fara 2 
stael sta.2 stay3 sta.4 sta. 
One-third of horses 
4 have arrived at Sta.2 
2 
'¢) <> > ae out: i cally ce fete) cuD Ge ee GE Gee eel aoe ew cee cme oe ee fos oe ae oe a ee -_ 
sta.el sta-e2 stae3 sta.4 sta.5 
All horses’ have 
4 passed station 2 
2 
Q 4------}-----~-}------}----~---------- 
sta.el stae2 sta.3 sta.4 sta.5 
Lead horses arriving 
4 at sta.3 and sta.el has 
moved to sta.5 
2 
Q 4-----4------4-------}-----+-4------ = 
sta.l Sian sta.3 sta.4" sta.5 
Figure 5. Channel activity in packets per 


minute remains relatively constant although 
reporting responsibility moves from station 
to station. 


Station-to-Station Messages 

An enhancement to the basic database 
system described above is the addition of 
a message packet format that allows the 
exchange of text messages among the packet 
stations. The format of figure 6 is used. 


#mLDNNLLnow is the time for all good men 


Message text 

2 digit line number 

2 digit message number 
Destination (location) 
Originator (location) 
Message format identifier 


FiLGUre: “6. Message packet format includes 
line number and message number to assure 
message integrity over the unconnected 
eta: 

Point to point messages are programmed to 


require a specific acknowledgement, while 
system-wide messages or _ broadcasts are 
scheduled for periodic update. Smaller 
systems (4K) may retain only the last 
message while larger systems may desire to 
retain all messages until cancelled. 


Data Array Compression 


For array processing, the individual 
display terminals should be programmed to 
accept each report and use the time, 
location and status to update its data 
base. To save memory, the gaps in the 
item number series suggest the computation 
of offset values for each of the number 
series and using these offsets to compute 
an actual array address. This means that 
on initialization, the program queries the 


user for the total number of entries 
expected in each of the number groups and 
uses these as offsets for the array 


approach, the 
needs to be dimensioned 
no larger than the sum of these offsets 
and only a single computation needs to be 
performed for each array access. 


subscripts. Usang: «this 


total array size 


The scheme to significantly compress 
the number series into a contiguous array 
is as follows: 


ue fy 
INPUTNumber of series ? ; NS 
FOR I=1 TO NS: 
INPUT&art and end values?'; 
R(i)=E(i)-S(i) : RANGE 
A(i)=A(i-1)+R(i-1) :ARRAY OFFSET 
D(i)=A(i)-S(i) :DELTA OFFSET 
NEXT 
Now, given a horse number 4H, its array 
location, A, may-be found using the loop: 


S(i),E(i) 


FOR i=1 TO NS 
IF H<E(i) THEN A=H-D(i): i=NS 
NEXT i 
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And any array number, A, may be converted 
back to an item or horse number using the 
loop: 


FOR i=NS TO 1 STEP -1 


IF A>ACi) THEN H=A+D(i): i=l 
NEXT i 
Finally, some consideration should be 
given Lo the scheduling of packet 


transmissions according to the loading of 
each particular station. Using 4 minutes 
as a nominal refresh cycle period, each 
station should time the delay between each 
packet transmission inversely proportional 
to the number of packets it needs to send 
or a minimum of once per minute if he only 
has one packet. With a peak load of 200 
reports or 25 £4packets per period, the 
minimum delay between packets should _ be 
about 10 seconds resulting in the 


following relation: 


N = INT( R/8) +1 D = 290 /( Nt4 ) 
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Where D is the delay in seconds between 
each packet transmission, N is the number 
of packets due for transmission computed 
from the number of reports R. 


The purpose of this paper is to 
suggest early agreement on the format of 
the data distribution packets so that 
AMRAD packet owners can begin working on 
the display formats and querie/response 
capabilities of their individual systems. 
They may add as many bells and whistles as 
they feel necessary, such as pointers to 
string arrays containing the full names 
and statistics of all horses, runners and 


people. Dependjing on these bells and 
whistles, there should be no~- problem 
FicCtang “Up: “LO 200 horses, runners and 


VIP's into less than 4K for a VIC-20. 


The requirement t 0 provide emergency 
communications coverage for large public 
race events iS a frequently repeated 
amateur radio public service event. 


Hopefully bringing the benefits of packet 


radio to bear On this application will 
demonstrate the tremendous potential for 
this state-of-the-art mode of 
communications. 
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Introduction 


This pa er will review the status and 
Proce eo ice: the various layers in the ISO 
International Standards Organization) Open 
Systems Interface Reference Model (OSI-RM) as 
applied to amateur packet radio. 


Some amateurs believe that the OSI-RM 
provides a good basis for the development of 
computer networking via amateur radio because of 
the flexibility it allows. Others see that same 
flexibility as a lot of unnecessary overhead that 
takes its toll in reduced throughput and added 
complexity at actual network implementation. Even 
the most die-hard supporter of OSI-RM must admit 
that it is less than optimum, especially at the 
network layer. I believe however, that it is the 
best game in town at this point, and what we 
amateurs have implemented so far falls neatly into 
the OSI-RM architecture. 


Overview 


The OSI Reference Model for a modern data 
communications system is broken into seven 
distinct levels. The terms level and layer are 
used almost synonymously whenever the OSI-RM or 
its levels are discussed. Actually, when 
describing or referring to the function, level is 
generally considered the correct term, and when 
calling a particular level by name, layer is more 
often used. Thus, the first level of the 
Reference Model, Level 1 is called the Physical 
Layer. A small point I admit, but one we should 
keep in mind. 


The seven levels that make up the OSI-RM are: 


Level 7. Application Layer (highest level) 
Level 6. Presentation Layer 

Level 5. Session Layer 

Level 4. Transport Layer 

Level 3. Network Layer 

Level 2. Link Layer 

Level 1. Physical Layer (lowest level) 


Fach one of these levels has certain 
responsibilities to make sure data travels from a 
source device to a destination device accurately 
and promptly. 


Each of these levels communicates with its 
peers along the overall network as Cierra 
using its associated lower level as the 
communication medium (except for Level 1, which 
has no lower level). All information received 
from an uPeSe level by a lower level should be 
considered as data and not altered beyond what 
may be done to enhance communication of the data 
within that level (this includes any headers 
required by the upper levels). 


It should be noted that there is potential in 
the. OSI=RM for alot -of copitetty of functions, 
depending on what protocol is implemented at each 
level, and how complex the resulting network is. 
This is especially true when the affect of 
multiple levels of multiplexing data paths is 
considered, as most levels allow. Simpler network 
systems may leave out certain levels because they 
just don't apply, or add unnecessarily to the 
complexity of the overall system. I would 


recommend that if any level is bypassed, at least 
one null character is inserted where that level 
would otherwise go, leaving the network designer 
with an "out" in case that level is deemed 
necessary at a future date. 


One of the major advantages of the OSI 
Reference Model is that it will (hopefully) allow 
substitution at any one of the individual levels, 
without seriously affecting the other levels of 
the overall network. This means that one area can 
use the same Network Layer, for example, as 
another area, while implementing a totally 
different Link Layer protocol. This not only 
allows for creative implementations at any of the 
levels, but also allows for each level to suit the 
need of its medium. 


A good example of this might be the creation 
of different Link Layer protocols depending on the 
communications medium used (meteor scatter likes 
smaller frame sizes than VHF/UHF terrestial 
cnamner oi while using the same Network and higher 

ayers. 


As mentioned above, this design does have its 
weaknesses. Sometimes, the levels need to be 
broken down further than they are (such as the 
Network Layer into the Network Sublayer and 
Internetwork Sublayer), while other times there 
seems to be a problem effectively separating 
different levels (the Datagram type Internetwork 
Sublayer relies on the Datagram Transport Layer 
heavily for proper operation). This paper will 
discuss the various levels independantly, and try 
to account for any interdependance as necessary, 
starting with the lowest level, and working 
peers I will also mention some of the 
alternatives at various levels, and make some 
recommendations based on my opinions as of the 
date of this paper. 


Level 1, The Physical Layer 


Level 1 is the lowest level in the OSI 
Reference Model. It is concerned primarily with 
the "real world" part of sending and receiving 
data. This is not as small a task as initially 
thought. There are several parts that make up the 
whole Physical Layer, including: 


Voltage levels. 

Data and handshaking signals. 

Speed of data transmission and reception. 
Order of bit transmission and reception. 
Modulator/Demodulator (Modem) types. 

RF signalling channels. 


All of these different parts have to match 
each other at both ends before any data can be 
transferred from one location to another. 


Typically, data at the Physical Layer is sent 
over a radio channel in a serial bit stream. The 
interface between the users terminal or computer 
is generally also serial, usually asynchronous 
ASCII, at speeds between 300 and 9600 baud. In 
serial operation, RS-232C is the common interface 
for defining voltage levels, data and handshaking 
Signals, the types of connectors used, and their 
pinouts. 


The data speed and modem type are related to 
the RF signalling channel used in amateur packet 
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radio communications. Tt. Ls: very - ditticult:. to 
design a modem that will allow data transfer at a 
rate of 56kbps (kilo-bits-per-second) over a data 
path using the HF frequencies. It is beyond this 
paper to specify optimal data rates and modem 
types for all aspects of amateur packet radio, 
rather, I will discuss some of the more common 
systems presently being used or being actively 
discussed. 


VHF/UHF Operation 


There is only one commonly used standard 

on VHF/UHF at the moment. Lt. ~iis., the- Bell -202 
modem, running at 1200 bps. This is an extremely 
opular standard in that it affords a relatively 
ast speed of operation (compared to 60 wpm 
Baudot), et does not require special radios or 
other difficult to obtain equipment. There are a 
lot of surplus 202 type modems available, along 
with several simple modem designs. There are even 
Single-chip modems becoming available (such as the 
AMD 7910) that do the whole modem magic in one IC. 


Even satellite operation is bein 
experimented with, using the above mentioned 20 
standard. Some users are finding that some modem 
designs (sucn as the phase-locke -loop modems) are 
not functioning as well as others, primarily due 
to the inferior signal-to-noise ratio SSB over a 
satellite gives as opposed to VHF FM. 


There is some experimentation going on 
with higher speeds, particularly on the 220 MHz 
band, where we are allowed to run up to 56 kbps. 
The present experimentation generally consists of 
speeds up to 9600 bps (the speed where most HDLC 
chips internal clock recovery circuits start to 
die ), using different modulation and demodulation 
techniques. One of these is to not use the 
classic concept of a modulator and demodulator, 
but rather shift the RF carrier some specified 
amount at the transmitting end, and take the 
output of the discriminator output directly from 
the receiver, before any audio processing. This 
technique is actually quite old (relatively 
speaking), some of the early packet experiments in 
Canada used this technique quite well at speeds up 
to 4800 bps. The drawback to this system is that 
it requires the modification of the radios to be 
used, and may not ive enough of an increase in 
speed to warrant a long-term commitment of time 
and materials necessary to develop the system. 


There is the potential for a lot more 
experimentation in the VHF/UHF area, including 
extremely high speeds using microwave RF 
technology such as gunnplexers. 


Meteor Scatter 


Some experiments using meteor scatter 
are in the design stage. These tests will 
probably be conducted on 6 meters, with stations 
about 600 to 900 miles apart (optimum meteor 
scatter range). Due to the extremely short 
duration of meteor scatter paths, high speeds and 
small packet sizes will be the order of the day. 
This may cause special rotocols to be developed 
to reduce the amount of overhead required, and 
take into account the sporadic nature of this RF 
medium. 


HF Operation 


There is some HF packet operation going 
on now, with the promise of a lot more in the near 
future. HF can allow a major jump of physical 
space in a single hop, if the correct frequency of 
operation is chosen. HF does have its own set of 
peculiarities to deal with, such as narrowness of 
the channel bandwith, selective fading of 
different frequencies within the channel, and 
intersymbol distortion due to the RF energy taking 
multiple paths to reach the other end. 


Some of the initial tests were conducted 
on 40 meters using the VHF standard 202 type 
modem, running at 300, 150, and even 75 bps. The 
reason for this initial choice was that the 
equipment was already hooked up and operating, but 
it was found that this system leaved a lot to be 
desired. The major problem in this system was the 
wide bandwidth necessary to be clear of 
interference (202 modems use FSK with one tone 
being 1200 Hz and the other being 2200 Hz, 
resulting in a shift of 1000 Hz, requiring almost 


the whole 1000 Hz to be devoid of other signals, 
no small feat on 40 meters). 


One answer to this modem problem is the 
Packet Adaptive Modem designed by Paul Rinaldo, 
W4RI. and Robert Watson. This modem uses a 
relatively new technique to uamateurs, Minimum 
Shift Keying or MSK, for the transmission of data. 
It will eventually be able to run up to 1200 bps 
with a channel bandwidth equivalent to a 600 Hz 
shift FSK modem. The design is completed, and 
some of the boards are being teste now. The 
finished system will be written up in an upcoming 
issue of QST. 


Another set of experiments being 
conducted uses a 200 Hz s'hift FSK modem running at 
300 bps. Bob Bruninga, WB4APR is among the grou 
testing this system on a regular basis on the 1 
MHz band, using surplus Bell 1.03 type modems. The 
30 meter band has some real. advantages to the 
packet user, the main one being the lack of QRM. 
Bob routinely maintains connections for up to 
several hours at a time now, implying this may be 
a reliable method of transferring packets over a 
medium distance. 


The Physical Layer is the only level that 
maintains an actual "physical" or ''electrical" 
connection with its peers. The rest of the levels 
communicate with their respective peers through 
assigned “Logical™ -or “virtual’ connections. 
Since these logical connections aren't part of the 
real, phyeicat world but rather system concepts 
implemented in computer programs, there must be an 
actual computer device used to implement these 
protocols. These computer programs run either as 
a portion of a mainframe program, or, more 
frequently, in a smaller, dedicated computer. 


Level 2, The Link Layer 


All this leads us to the Link Layer. This 
level is responsible for receiving and sending 
data from the higher level protocols and sending 
that data to or receiving the data from the’ the 
Physical Layer, respectively. Part of this 
responsibility is to maks sure that data 
integrety is maintained through the peice: 
devices implemented, and recovering rom any 
errors occuring in the physical world., 


Figure 1 shows several types of devices 
interconnected as a portion of an amateur packet 
radio network. Note that there is a separate link 
layer that corresponds to each Physical Layer. 


In order to insure data integrity over the 
Physical Layer, the Link Layer does several things 
to the data it receives from the higher levels. 
Most Link Layer protocols start by taking the data 
received from the higher level and creating small 

roups of data, called frames, then sending these 

rames to the Physical Layer for actual 
transmission. Most ink protocols add a certain 
amount of overhead at the beginning and end of the 
actual data to be sent. This overhead usually 
consists of an assigned number of the frame, frame 
type identifiers, rame source and/or destination 
identifiers, and some sort of mathematically 
derived number that is used as a check to make 
sure both sides of the physical interface have the 
same data. These basic functions are described in 
an ISO standard (ISO 3309), commonly referred to 
as the High-level Data Link Control protocol, or 
HDLC. 


There are two versions of Link Layer 
protocols commonly used in amateur Packet radio 
today. Both follow the HDLC standard for the 
addition of flags, address, control, and Frame 
Check Sequence fics) fields. The flags are used 
to indicate the beginning and end of the frame, 
the address field is used to indicate who the 
frame is from and/or going to, the control field 
is used to show what type of frame is being 
conveyed, and the FCS field is a cyclic-redundancy 
check calculated on the data between the opening 
and closing flags. 


In order to assure t*he flag character 
(01111110) does not appear anywhere in a frame 
except at the beginning or end, anytime five or 
more one bits are found in the data, a zero bit is 
added after the fifth one bit. The receiving end 
will realize that the zero was added, and delete 
ae 
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The first thing most Link Baye! protocols do 
is toestablish a “virtual” connection between the 
two devices wishing to communicate. This allows 
both devices to know what mode each is in at any 
given time. In order to make and maintain this 
connection, certain types of frames are sent back 
and forth that don’t carry any user data, but 
rather perform command or supervisory functions 
related to the status of the fink There are also 
supervisory link functions to make sure one device 
doesn’t “overload” the other with data faster than 
the receiver can handle it. 


Vancouver Protocol 


The first Link Layer developed for use 
on the ham bands was based on the IBM variation of 
HDLC, called SDLC. This protocol was developed by 
Doug Lockart, VE7APU, the “father” of packet radio 
on the ham bands. It is connection oriented, and 
uses eight-bit address and control fields, along 
with the standard CRC for the FCS. There are a 
few supervisory frames necessary for creating and 
maintaining the connection, along with flow 
control frames to prevent overloading. The level 
2 Vancouver protocol works fine, and its overhead 
is minimal. 


AX.25 Level 2 


After the AMRAD group used the Vancouver 
protocol for a while, it became obvious that there 
were some limitations to this protocol. The main 
limitation had to do wit the addressing 
information imbedded in each frame. The Vancouver 

rotocol uses eight bits for the addressing 
nformation. Some implementers of the Vancouver 
protocol modified it so that the addition of 
digital repeaters” or digipeaters could be used. 
These additions took up two of the eight bits in 
the address field, leaving six bits for actual 
addressing. This meant that only 64 users could 
be addressed before overflow was reached. In 
addition, someone in each group had to assign 
these numbers to stations, and make sure that 
numbers weren’t assigned twice. 


AX.25 took care of this by installing the 
amateur’s callsign in the address fiielki. One more 
addition saw both the source and destination 
addresses in the address field. This meant that 
the address field of a frame jumped from one byte 
to 14 bytes in a single bound! A further addition 
saw first one, and now up to chen digital 
repeater addresses in the address field. Talk 
about overhead! Unfortunately, in order to design 
a system that hams can use easily, a system like 
this is almost a necessity. 


In addition, AX.25 added more supervisory 
frames, and is designed to be more flexible in 
higher speed and full duplex systems. Most 
amateurs using packet radio today are using the 
AX.25 Level 2 standard, and all packet systems 
available today can support the AX.25 Level 2 
protocol. 


AX.25 also allows multiple link connections, 
so that several stations can be interconnected. 
This includes connecting to one’s self, allowing 
testing of packet software if there are no other 
stations around (as long as there is a repeater 
available). 


to read more about these 


Those wishin 
to to the following: 


protocols should re 
Vancouver protocol available from: 


Vancouver Amateur Digital. Communications 
Group (VADCG 
c/0 poue OC er VE7APU 
9531 Odlin Road 
Richmond, B.C. V6X 1El 


AX.25 Level 2 protocol specification: 

Second ARRL Amateur Radio Computer Networking 

Sr Proceedings available from the ARRL for 
Dali, 


Updates on the AX.25 Level 2 protocol 
are available in the AMRAD Newsletter. 
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Digital Repeaters 


Both the modified Vancouver protocol and 
the AX.25 Level 2 protocol support devices called 
“digital repeaters” or “"digipeaters". These type 
of repeaters differ from the normal voice type 
repeater in that they generally operate as time- 
domain, or store-and-forward repeaters rather than 
the frequency-domain system used by voice systems. 
What this means is that a repeater will listen to 
a frequency for frames it should repeat. When it 
hears one, it pulls it into its memory, checking 
to be sure there are no errors, and then waits for 
the sender to drop its transmitter. The repeater 
then re-transmits the frame on the same frequency. 
This allows several packet stations to communicate 
over a Single frequency that might not otherwise 
be able to hear each other. Since a single 
frequency is used, spectrum usage is cut in half. 
In addition, the repeater is usually a very simple 
device, since no cavities or filters are required. 
Level 3. The Network Laver 

The next level up the ISO-RM is the Network 
Layer. The units transferred at the Network Layer 
are called “packets”. This level probably should 
have been split into two distinct levels. The 
lower level, sometimes called the Network Layer or 
Level 3A, maintains control over a single, smaller 
network of users. The upper portion, called the 
Internet Layer or Level 3B, interconnects these 
smaller groups into a larger network, allowing 
individuals or systems in one group to communicate 
with others in different groups if they want. 


At this point, I think it would be 
advantageous to discuss for a moment the two basic 
types Of network designs, the connection oriented, 
and the connectionless (clever name) or Datagram 
type. These two systems differ greatly in their 
design philosoph but either can be used in place 
of the Sther wit Wout adverse affects. 


Some think that a whole network and 
internetwork must be the same 12; or 
communications cannot happen, but with the proper 
eoparat ton of functions, gateways can be built 
allioowinn different systems at almost any level. A 
gateway is a device that transforms ohe type of 
protocol that exists on one side of it to a 
different Ryne DEOtoce® being used at the other 


side of it. | When properly designed, petese s are 
capable of interfacing two completely different 
sty le protocols to each other, as if the 


difference didn’t exist. 

Getting back to the two types of networks, | 
first: discuss the -connection,oriented 

followed by the connectionless type. 


will 
network, 


Connection Oriented Network 


The connection oriented network operates 
very Similarly to the Link Layer protocol. In 
order to transfer any user data across the 
network, a “connection’ must, first be made from 
one user to the other. This involves passing 
between the two stations (and any networ 
controller that May exist) a connection request 
and acknowledgement. Once this connection is 
made, any data travelling between the two users 
must travel through the path established at the 
time the connection was created. If any 
unrecoverable errors, .cccur;, the ‘defective 
connection must be torn down, and a new connection 
must be made, if possible. 


Some of the advantages of a connection 
oriented protocol are: 


ite Lower overhead per packet once a connection 
is made, since all information about who is 
communicating and what path is being used is 
sent only once (when the connection is being 
generated). This lower overhead usually 
Simplifies the software necessary to 
implement the protocol. 


Out-of-sequence packets *generally aren’t 
allowed, agaim simplifying the software 
needed to implement the network protocol, and 
also simplifying the higher level protocols. 


a Connection oriented protocols are generally 
easier to implement than datagram type 
protocols. 


4. Once a connection is made, the routing of 
packets doesn't have to :be recalculated over 
and over (and over and over) and over again. 


Some of the disadvantages of the connection 
oriented network protocols are: 


dis Since the route of data flow is established 
at connect time, if there is any failure 
along the path chosen, the connection must be 
torn down and re-established using a 
different path. This implies that an 
network using a connection oriented protocoL 
should be as reliable as possible. 
Unreliable networks may take a longer amount 
of time to keep the network running than 
actually pass data. 


Zz If part of the network becomes overly 
congested, Since there is no ‘way to 
dynamically alter the path used in a 
connection, the congestion will become worse 
as time progresses, unless there is a way. to 
automaticaIly tear down and re-estab {ish 
connections around the congested portion. 


Si Out-of-segquence packets aren't normally 
allowed, causing Accurately received packets 
to be rejected because of badly received 
earlier packets. This -Could— ~cauge. an 


increase in channel occupation, reducing 
effective channel throughput. 
4, If a station is moving through areas covered 


by connection oriented networks, it could 
have a problem when the time comes to leave 
one area and go into another. How a roving 
station can be passed from one network to 
another in connection oriented networks isn't 
a big Pee presently, but_it could become 
a problem as the use of packet radio 
increases. 


There are more advantages and 
disadvantages for the connection oriented 
protocols, but those mentioned above are the most 
important. 


Connectionless Protocols 


The connectionless type of protocols 
(called the datagram type from here on) operate in 
a different manner than the connection type. In a 
datagramprotocol, all information needed to get a 
packet from the source to its destination is 
included in the header of each packet. Obviously, 
this will cause the header to become larger than 
the equivalent packet of a connection oriented 
network. In addition, each packet's routing must 
be decided independantlv from others either 
leap) or succeeding it, causing a lot of 
additional operating overhead while each packet 
Switch decides the b&t way for this packet-to go. 
This can come in handy when a network is not too 
reliable, or when a portion of a network becomes 
congested, since the path taken by packets can be 
dynamically altered. This doesn't come cheaply 
however, it usually takes more computer power to 
make sure a datagram type network functions 
properly. 


As the last Bea illustrates; - ‘the 
se) tale poe and disadvantages between connection 
oriented networks and datagram type networks are 
generally just the opposite of each other. 


Level 3A. The Network Sublaver 


The Network Sublayer is responsible for 
taking data from the higher level protocols, 
pee it, and sending it to the Link Layer 

or actual transmission through the Physical 
Layer. While the Link Layer is responsible for 
mat aac sure the user data accurately transverses 
the physical link between two stations, the 
Network Layer is responsible for making sure that 
user data passes through any intervening nodes, 
such as metropolitan network controllers or packet 
Switches. Along with this, the Network Layer 
makes sure that any data from another network 
either passes through the network successfully, or 
reaches the destination station if that station is 
part of the metropolitan network. 


When I first began to study protocols 
above level 2, I was impressed by the datagram 
type of network. It seemed to have a lot goin 
for it. especially ina relatively ieetruceured 
and potentially unreliable amateur radio packet 
network. Datagram networks are very forgiving by 
nature, allowing for the voluntary nature of 
amateur stations showing up, and then 
disappearing. 


Then we found out how people were 
implementing datagrams, and on what type of 
machines. It seemed that most people were 
implementing datagrams on large computers or mini- 
cornp uters. There didn't seem to be a practical 
implementation of a datagram network based on 
microcomputers. 


In addition, the two major commercial 
data networks seemed to be implementing connection 
oriented networks very effectively, including the 
use of microcomputers in their implemenations. 
This is when I started taking a second look at the 
CCITT standard X.25, both at level 2 and level 3. 


About the same time, Gordon Beattie Jr, 
N2DSY, was coming to the conclusion that X.25 
would be a good place to start on establishing a 
standard protocol for levels 2 and 3. In the 
summer of P82, Gordon came down to the Washington 
area, and we had a conference with Eric Scace, 
K3NA, at Telenet. 


Eric became a valuable asset in our 
discussions, Since in addition to working at 
Telenet, he served on the CCITT committee on X.25. 
It turns out that there can be a large difference 
between what a protocol document appears to ook 
and how the protocol is actually implemented. 
This is where Eric really helped, by giving us 
insight not only into w'hat the protocol designers 
meant, but also how the real world networks 
implemented the protocol. 


As a result of these meetings, we came 
up with drafts of protocols for both levels 2 and 
3. Level 2 eventually grew into the AX.25 Level 2 
that most packeteers are now using. Level 3 is a 
much larger, more sophisticated protocol, and as 
such, requires more careful analysis to see what 
we need and what we don't in the amateur 
community. As with level 2, we can't just throw 
out portions of the protocol without making sure 
they wont be needed in the future. 


A separate paper in these proceedings 
discusses the level 3 protocol in some detail, so 
I wont get describe it in detail here. It is 
based on the CCITT X.25 Level 3 protocol, using 
“virtual circuits”. Permanent virtual circuits 
weren't deemed to be useful, at least at this 
point, in the amateur service, and the Datagram 
service of X.25 was eliminated by the CCITT 
because of lack of interest. 


One of the main arguments used against 
connection oriented networks is that they aren't 
very forgiving in unreliable enviroments. It 
seems that most metropolitan networks should be 
reliable enough to support connections without 
major problems. Since connections require less 
channel overhead than datagrams, this should also 
allow more efficient use 0f RF frequencies. 


The recommendation to go AX.25 at the 
Network Sublayer is not cast in stone, but it 
appears that this is the best compromise protocol 
to use at the local or metropolitan level. 


Internet Sublayer 


The Internet Sublayer is the next step 
(or half-step in this case> up the ladder to the 
user. This level isn't necessary for purely 
local or metropolitan communications, since the 
data at that level isn't intended to go outside 
the individual network. The Internet Sublayer is 
only necessary when data must flow outside a 
single network s_ boundry. 


Since the Internet Sublayer is 
responsible for the transfer of data across 
individual networks to the destination network, 
there must be enough addressing information in the 
level 3B header to make sure the packet can be 
successfully routed to its destination. The 
internet protocol is also responsible for making 
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sure any fragmentation of large packets into 
smaller packetS is done in an ordérly fashion. 


The amateur community is very inventive, 
and often likes to use whatever is invented 
locally rather than using a “standard” foisted on 
us by some outside group. Keeping this in mind, 
and also keeping in mind the potential of some 
networks being not as reliable as others, I 
propose that we use a datagram type of internet 
protocol. Even though datagrams might require 
more computer power to implement, not every 
user will be required to have this overhead, since 
the internet protocol is used to interconnect the 
individual networks, not each user. 


Among the datagram type internet 
protocols available are the DARPA internet 
rotocol and the National Bureau of Standards 


NBS) internet protocol. These two are very 
Similar, in fact the NBS standard grew out of the 
DARPA one. It seems that either of these might 


suit our needs with some slight “adjustments” for 
amateur peculiarities. The main difference 
between these two is that the NBS version has 
eye address fields (which we may need). The 
DARPA internet adds a minimum of 20 bytes of 
header (more for options), while the NBS version 
adds a minimum of 28 bytes. Otherwise, both look 
almost identical. Figure 2 shows the outline of 
an NBS internet header. Unfortunately, it is 
beyond the scope of this paper to discuss the 
operation of these protocols. 


One important thing to keep in mind when 
discussing internet protocols, particularly the 
datagramtype, is that the internet protocol must 
work yey closely with the next level protocol, 
the Level 4, or Transport Layer protocol. The 
datagram type internet assumes that a rather large 
transport protocol resides above it, making sure 
that any alterations of data that might OP up 
due to internet operations (such as packets 
arriving out of sequence) are properly corrected. 
This interdependence is why the internet and 
transport levels are often referred to as one 
combination protocol (such as TCP/IP which means 
Transmission Control Protocol/Internet Protocol). 
It is important to keep this in mind when 
designing or implementing an internet protocol. 


As mentioned before, just because a 
datagram type of protocol is chosen for the 
Internet Sublayer, this DOES NOT mean that.a 
datagram Network Sublayer must also be 
implemented. This is just NOT true. In fact, 
included in the NBS documents on the NBS internet 

rotocol is software describing an interface to an 
-25 Network Sublayer. The two are separate 
items, and should be delt with as such. 


Level 4, The Transport Layer 


The main function of the Transport Layer is 
to make sure the data passed on from the higher 
levels at one side of a group of networks 
interconnected ne ng an internet protocol is 
received at the intended destination correctly. 


Part of this responsibility is to make sure 
the data is received in the same order as it was 
sent. Indatagram protocols, it is possible for 
one packet sent before another to arrive at _the 
destination network after the second one. This 
could cause big problems if left uncorrected. The 
Transport Layer must make sure all packets are in 
the correct order before sending them. “on. up: the 
ISO-RM ladder to the higher levels. This may 
involve buffering the packets for a period of 
time, potentially requiring large amounts of 
memory. 


Another responsibility of the Transport Layer 
is to notify the originating network that the 
packet successfully reached the destination 
network. In addition, the Transport Layer may 
impose flow control procedures on packets as 
necessary. 


As mentioned earlier, the Transport Layer 
works very closely with the Internet Sublayer. 
This means that if the DARPA internet is used, the 
DARPA transport protocol should also be used. The 
DARPA transport protocol adds an additional 20 
bytes minimum of overhead as a transport header. 
If the NBS internet is oe the NBS transport 
protocol should also be implemented. The NBS 
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version is more complicated than the DARPA 
version, and some of it might have to be thrown 
out if it is to be used on a microcomputer system. 


Level 5, The Session Layer 


Now that the data has transversed the network 
successfully, it is ready to be used by the 
intended destination device. If that destination 
device is a larger computer, capable of running 
several programs Se eed there must be a 
way of telling which program the received data is 
intended for. This is part of the responsibility 
of the Session Layer. 


One example of this might be Dave, K8MMO's 
svstem having someone running an orbit prediction 
program the same time as another person is editing 
a document, both running under MP/M II. The other 
example might be having several -different people 
using the same program, such as a bulletin board 
program, at the same time. 


The Session Layer adds its own overhead to 
make sure the proper application (be it a program 
or another user) gets the correct user data. The 
Session Layer introduces a new term for the block 
of data it deals with, the "messai@”. Within the 
overhead that the Session Layer adds is some sort 
of out te information to insure that the data 
received from the network is sent to the proper 
program within the computer, which is referred to 
as a “port”. These ports are generally assigned 
names by the application being run. 


The Session Layer also makes sure that an 
Operating session between a user at one end and 
the program at the other end is handled smoothly. 
If the user should suddenly disappear from the 
system, it is up to the Session Layer to inform 
the application of this problem, so that the 
application can take any action deemed eh dagarageres 
This implies that the Session Layer not only 
handles data between the network (via the 
Transport Layer) and any applications involved, 
it also passes some status and control information 
between the network and the application in 
question. 


The Session Layer is not a necessity in a lot 
of instances, such as two people typing back and 
forth ala RITY mode. In this case, the Session 
Layer overhead could be considered unnecessary 
and eliminated. 


The Session Layer is a subject that needs 
further study at this time, as there are several 
versions out (DARPA, NBS, CCITT. BX.25 etc). 
Since there aren’t a lot of mainframes on the a 
packet networks so far (there isn’t even a network 
as such), there is time to study this level 
carefully before making a commitment to any 
particular standard. 

Level 6. The Presentation Laver 

The Presentation Layer is responsible for 
making sure that the data passed from one end of a 
hook-up to the other end makes some sense, and is 
displayed in an orderly fashion. It specifies 
things such as what character code is used and 
screen and printer display control sequences (such 
as cursor addressing). 


The Presentation Layer can be a_ very 
complicated system, or it can be a null level, 
depending on what type of devices are being used 
at each end. 


If, for example, a glass TTY (such as is used 
for the hearing impaired) is to be used with a 
version of a word processor set for a Heath H-19 
terminal, the Presentatin Layer would be very 
complicated. Not only would there be code 
conversions required (ASCII vs Baudot), but also 
screen formatting characters would have to be 
converted, along with other problems. The end 
that would do the conversion would depend on what 
type of Presentation Layer protocol had been 
agreed to by the users of the system. 


If a different user was to use the same word 
processor with a Heath H-19, and the Presentation 
Layer protocol agreed to was the H-19 Peas 
ASCII, the Presentation Layer at both ends coul 
end up being a null level, since the same protocol 
is implied at both ends. 


Level 7, The Application Layer 

Application Layer protocols are primarily 
concerned with how a particular program is 
operated by the user of the rogram. The 
application protocols are Sera lished so that 
users (be they individual or another program) will 
know ae to correctly use a program through the 
network. 


The Application Layer, being the top of the 
system, would normally be the last area to look at 
for standardization. Since there are a myriad of 
programs that could be run as application programs 
over the amateur packet radio network (and a lot 
more not even thougnit of, or written yet) this 
could Sf uP being the hardest set of protocols to 
come up with. 


Iwo types of programs that should have 
standard protocols written for fairly quickly 
oe They are the message system (generic 
name) and the file transfer programs. 


There are many message system programs 
available to the amateur today. It seems that 
every one of these systems uses different commands 
to operate it, along with a different message 


format. It would help greatly if there could be a 
ah a standard set of commands available, alon 
wit: a standard message format. Then, eac 


message system along a network could potentially 
access other message systems along the network, 
and automatically grab off any pertinent data. 
Also, there could then be defined within this 
message system protocol, a way of automatically 
forwarding messages arate the network from a 
source message system to the destination message 


system. 
There are many different message systems, and 
many different message system "standards" already 


in existance. DARPA has a standard, so does NBS, 
and the CCITT just ot name a few. This is an area 
I haven't delved into too far yet, so I have no 
feeling at this time as to whichprotocol would 
best suit our needs. Some Sate Tal work is being 
done by Paul Rinaldo, W4RI, Hank Magnuski, KA6M 
Larry Kayser, WA3ZIA, along with the AMSAT and 
VITA contingent on message system standardization. 


The other Presentation Layer protocol that 
needs almost immediate attention is the file 
transfer protocol. A lot of us are presently 
using the Ward Christensen protocol so prevalent 
among CP/M users for exchanging CP/M files using 
modems over the phone lines. In fact, this 
protocol has been implemented in many computer 
systems other than CP/M, including 6800 type 
computers and (rumor has it) DEC minis. 


One of the faults with the CP/M file transfer 
protocol is that it uses a very simple checksum on 
the data transferred to make sure no errors crept 
into the transfer. There has been some 
modifications made in this area recently, some 
versions of this transfer program now allow either 
the original checksum routine or a more 
sophisticated CRC type calculation. Since there 
is so much redundant checking of data at the lower 
levels of a network, the more sophisticated 
version may not be needed. 


There is also a protocol for file transfer 
floating around that was developed by the NBS but 
I haven't had a chance to study it carefully 
enough yet to see if it would fit our needs. 


Conclusion 


The OSI-RM appears to be taking shape in the 
amateur acket radio network. There is some 
rotocol develcoiient work being done at almost all 
evels of the Reference Model, with most people 
working from the ground up at this point. 


One of the disadvantages of the OSI-RM is 
thet there is a lot of added overhead, as 
mentioned at the beginning of this paper. This is 
primarily because multiplexing of different data 
paths is allowed at each level, causing multiple 
flow control procedures and addresses to be 
required at each level. 


An alternative to the OSI-RM system mi ght be 
to break the overall network design at different 
places. Eliminating the redundant capability of 
multiplexing of operations at each level would 
reduce the total amount of overhead required. 
This would have to be done very carefully. 


It is hoped that this Paes will help the 
newcomer to amateur packet radio understand how a 
data network is designed and implemented using the 
OSI Reference Model to allow a maximum of 
flexibility to the designers and implementers. I 
further hope that this paper stirs interest in the 
more Pekan radio enthusiasts by stating 
my Opinions and suggestions on recommendations at 
the various levels of the OSI-RM. 

Comments or su 
of this paper should be addressed to the author at 
the above address, or be sent to the Amateur Radio 
Research and Deveiopment (AMRAD) Newsletter tor 
publication at the following a 


owing address: 
Amateur Radio Research and Development 
O Drawer 6148 
McLean VA 22106-6148 
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NBS Internet Header Format 
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Introduction 


This is the first of four papers that make up 
a protocol recommendation for AX.25 at Level 3A, 
the Network Sublayer. 

This series of papers is being generated by 
AMRAD after a series of meetings between AMRAD 
members Paul Rinaldo, W4RI, Terry Fox, WB4JFI, 
Dave Borden, K8MMO, Eric Scace, K3NA, and Gordon 
Beattie, N2DSY. 


These papers are first drafts, and are being 
released to the amateur community for comments and 
suggestions. Anyone wishing to comment is invited 
to write to the author at the above address, or 
Leena to the AMRAD Newsletter at the following 
address: 


Amateur Radio Research and Development Corp. 
PO Drawer 6148 
McLean, VA 22186-6148 


The protocol recommendation that follows is 
based on the CCITT X.25 Level 3 specification. 
Since many amateurs may not have the CCITT 
documents available to them, it was decided to 
replicate the entire document, with additions or 
deletions necessary to apply the protocol to the 
amateur enviroment. 


This paper will discuss some of the basics of 
the Network Sublayer, along with operating 
procedures. The next paper will describe the 
actual packet formats. The third in the series 
will describe optional user requested facilities, 
and the fourth paper will include the Annexes 
mentioned throughout the previous three papers. 


AX.25 Network Sublayer Recommendation 


Network Sublayer Basics 


The Network Layer of the ISO Reference Model 
is generally broken into two different parts, each 
responsible for separate, distinct functions. 


Z 
3.0.1 


The Network Sublayer is responsible for the 
proper operation of a local, or metropolitan 
group of interconnected packet devices. These 
interconnected devices make up a network of packet 
users, who wish to communicate either with each 
other, or possibly with others outside of the 
metropolitan network. How the data is transferred 
outside of the metropolitan network is a function 
of the Internetwork Sublayer, and as such, falls 
outside the domain of this recommendation. 


The Network Sublayer relies on a lower level 
protocol (usually the AX.25 Link Tyee protocol) 
to cause data at the Network Layer to be 
transferred from one device to another. While the 
Link Layer protocol is responsible for the user 
data to transverse a physical medium properly, the 
Network Sublayer is responsible for the accurate 
transfer of data through the metropolitan network. 
This is usually accomplished by having individual 
devices interconnected to a master device (called 
a network controller, network hub, packet switch, 


or DCE). Any packet user wishing to communicate 
with another user (either within the metropolitan 
network, or outside it) does this through this 


master device. 


Subject for further study is how two stations 
communicate at the Network Sublayer in the absence 
of a packet switch. One proposal is to have the 
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two stations arbitrate which one will become the 
packet switch by a simple comparison of callsigns. 
3.0.4 Network Sublayer Responsibilities 

The Network Sublayer is responsible for 
taking data from the 'higher level protocols and 
sending that data to the intended destination 
device, foeeee the lower level protocols that may 
be implemented, 


Since the recommended protocol is connection 
oriented, in order to pass data over the network, 
a "virtual" connection must first be made with the 
destination device through a network controller, 
or packet switch. This recommendation handles the 
establishment, proper operation, recovery from 
errors, and tearing down of these connections 
necessary to pass data, along with the actual data 
transmissions. 


This protocol is also responsible for passing 
along certain status information of the network 
or lower levels to the higher level protocols. 


3209 


At the Network Sublayer there are two types 
of devices presently defined. Their descriptions 
have been adjusted slightly to take into account 
the amateur enviroment. Neither one of these 
devices are usually "real" devices, rather they 
are usually a software implemented "machine". 


Se ed 


At the Network pup bayerite be Data Terminating 
Equipment device, hereafter called the DTE, is 
pelle rae considered the individual packet user, 

e it an actual user, a remote network get enay or 
a large computer device running programs available 


Device Descriptions 


Data Terminating Equipment 


to other users. 
Bose Data Circuit-Terminating Equipment 


At the Network Sublayer, the Data Circuit- 
Terminating Equipment ‘Equipment device, hereafter 
called the DCE, is either the packet switch 
device or if there is no packet switch device 
availahnla, one of the DTE devices wishing to 
communicate. The arbitration of the second 
possibility is undefined at this point, and is a 
subject for further study. 


320.56 Units of Data Transferred at the 


Network Sublayer 


The basic unit of data that is transferred 
across a DTE/DCE interface is called a "packett". 
This packet is contained within the information 
field of Link Layer frames. All packets must 
Gontain -an, Integral. number of: “ockets. “in 
addition, the data field of data packets must also 
contain an integral number of packets. 


Sead 


Amateur X.25 defines only one type of 
connection at the metropolitan network level, that 
of the virtual call. Permanent virtual circuits 
and datagrams are not supported by by AX.25 as 
presently defined. 


Types of cannections available 


3.1 Logical Channels 


Simultaneous virtual 
calls to exist, logical channels are used. Each 
virtual call.is assigned a logical channel grou 
number (LCGN) (less than or equal to 15 decimal 


To) enable multiple 


and a logical channel number (LCN) (less than or 
equal to 255 decimal). A logical channel group 
number and a logical channel number is assigned 
during the call ene phase. The actual range of 
logical channel numbers available is established 
by the network, and agreed upon at the time of 
connection to the network. Annex A shows the 
recommendation of LCGN and LCN values used. 


3.2 Basic. Structure of Packets 


Every packet transferred across the DTE/DCE 
interface consists of at least three octets. 
Within these three octets are a general format 
identifier, a logical channel identifier, anda 
packet type identifier. Additional packet fields 
may be appended as apprepnrete Packet types are 
shown in Table 5/AX.25, 


From DCE to DTE From DIE to DCE 
Call set-up and clearing 
! Incoming call ! Call request 


| Call connected | Call accepted 
! Clear indication | Clear request 
[DCE elear ! DTE clear 
| confirmation ! confirmation 
| Data and interrupt 
! DCE data ! DTE data 
! DCE interrupt ! DTE interrupt 
{ DCE interrupt | DTE interrupt 
; confirmation confirmation 
! Flow control and reset 
! DCE RR ! DTE RR 
! DCE RNR ! DTE RNR 
! Reset indication ! Reset request 
: DCE reset confirmation ! DTE reset confirmation! 
| Restart 
! Restart indication ! Restart request 
! DCE restart ! DTE restart 
: confirmation | confirmation 
! Diagnostic 
! Diagnostic 


Table 5/AX.25 AX.25 Packet types 


.3 Procedure for Restart 


The restart procedure is used to initialize 
or re-initialize the network level DTE/DCE 
interface. The restart procedure clears all 
virtual calls at the DTE/DCE interface. 


Bc Sank Restart by the DTE 


The DTE may at any time request a restart by 
sending a restart request packet across the packet 
inter face. This will then place each aa 
channel in the DTE restart request state (r2), 


The other device (DCE or possibly another 
DTE) will confirm the restart by sending a DCE 
restart confirmation packet and placing the 
logical channels, used between the two devices in 
the ready state (pl). 


The DCE restart confirmation packet only 
applies to virtual calls between the requesting 
DTE and the receiving DCE. This restart has no 
affect on virtual calls with any other device 
Time spent in the DTE restart request state (r2) 
shall not exceed time-limit T20 (see Annex D). 


cee re Restart by the DCE 


The DCE may initiate a restart of the packet 
interface by sending a restart indication packet. 
All virtual calls for the specified packet 
interface are then placed in the DCE restart 
indication state (r3), While in this state the 
DCE will ignore all packets received from the DTE 
involved except for restart request and DTE 
restart confirmation packets. 


The DTE will confirm the restart by sending a 
DTE restart confirmation packet, and then place 
all virtual calls between sb) and the DCE in 
question in the ready state (pl). 


The action taken by the DCE when the DTE does 
not confirm restart within time-out T10 is given 
in Annex D. 


959455 Restart Collision 


Restart collision occurs when both the DCE 
and DTE simultaneously send a restart request and 
a restart indication packet. When this happens, 
the DCE will consider the restart completed. The 
DCE will not expect a DTE restart confirmation 
packet and will not send a DCE restart 
confirmation packet. This places all virtual 
calls between the affected DTE/DCE interface in 
the ready state (pl). 


3.4 Error Handling 


Table C-1/AX.25 indicates the reaction of the 
DCE when certain error conditions are encountered. 
Error conditions other than those specified in the 
table are discussed in sections 4 and 5 


3.4.1 Diagnostic Packet 


The diagnostic packet may be used to indicate 
error conditions when the usual methods (ex. 
reset, clear and restart with cause and 
diagnostic) are inappropriate. A diagnostic 

acket from a DCE should provide information on 
he error situations that are considered 
unrecoverable at the packet layer. Thass 
information permits analysis of the error, and 
recovery by higher levels at the DTE, if possible. 


A diagnostic packet is issued only once per 
particular instance of an error condition. A DTE 
receiving a diagnostic packet is not required to 
confirm reception. After a DCE sends a diagnostic 

acket, it will same in the same state for that 
topical channel(s) as it was when the diagnostic 
was generated. 


3.5 Effects of the Physical and Link Layer on the 
—— Packet Level 


Changes of operational states of the Physical 
and Link Layers do not implicity alter the state 
of each logical channel at the packet level. When 
changes that affect the packet level do occur 
they are explicitly indicated at the packet level 
oy, the use of restart., clear, or reset. procedures, 
whichever iS appropriate. 


A failure at the Physical and/or Link Layers 
is defined to be when the DCE cannot transmit or 
receive any frames because of abnormal conditions 
at the Physical and/or Link Layer. 


When a failure on the Physical and/or Link 
Layer is detected, virtual calls will be cleared, 
and further action may be taken as described in 
section 4.6. 


When the failure of the ae ar and/or Link 
Layer is recovered, the DCE will send a restart 
indication packet with the cause "Network 
operational" to the DTE. Any further action to be 
taken is defined in section 4.6 


In other out-of-order conditions on the 
Physical and/or Link Layer, the DCE will clear all 
virtual calls using the affected link. 


Note: An out-of-order condition on the Link 
Level includes reception of a disc command or a 
transmission of a disc command by the DCE, in the 
case of a single link procedure. 


4 Procedures for virtual circuit services 


4.1 Procedures for virtual call service 


Figures B-1/AX.25, B-2/AX.25, and B-3/AX.25 
in Annex B show the state diagrams which give a 
definition of events at the packet level DTE/DCE 
interface for each logical channel used for 
virtual calls. 


Annex C gives details of the action taken by 
the DCE on reception of packets in each state 
shown in Annex B. 


The ‘Gail. sary and clearing procedures 
described in the following paragraphs apply 
independently to each logical channel assigned to 
the virtual call service at the DTE/DCE interface. 
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4.1.1 Beddya t e 


If there is no call in existance, a logical 
channel is in the ready state (pl). 


4.1.2 Call request packet 


The calling DIE shall indicate a call request 
by sending a call request packet across the 
DTE/DCE interface, The logical channel selected 
by the DTE is then in the DTE waiting state (p2). 
The call request acket includes the called DTE 
address. The calling DTE address shall also be 
used. 


Note 1. A DTE address shall be encoded as 
described in Annex F of this 


document. 

Note 2. In order to minimize the risk of 
call collisions, the call request 
packet should use the logical 
channel with the highest number in 
the range allowed in Annex A that is 
in the ready state. 

4.1.3 Incoming call packet 


The DCE will indicate that there is an 
incoming call by pending across the DTE/DCE 
interface an incoming call acket. This will 

lace the logical channel in ne DCE waiting state 


p3). 


The incoming call packet will use the logical 
channel in the ready state with the lowest number 
in the range allowed in Annex A. The incoming 
call packet shall include the DTE calling address 
and the called DTE address fields encoded as 
described in Annex F. 


4.1.4 Call accepted packets 


The called DTE shall indicate its acceptance 
of the call b sending a call accepted packet 
across the DTE/DCE interface. This call accepted 
packet will specify the same logical channel as 
that of the incoming call packet. This places the 
specified. logical channe in the data transfer 
state (p4). 


If the called DTE does not accept the call by 
sending a call accepted packet or does not reject 
it by sending a clear request packet as described 
in paragraph 4.1.7 within time-out T1il (see Annex 
D), the DCE will consider it as a procedure error 
from the called DTE and will clear the virtual 
call aceordin to the procedure described in 
paragraph 4.1.8, 


Le ee) Call connected packet 


The reception of a call connected packet by 
the calling DTE specifying the same logical 
channel as that specified in the call request 

acket indicates that the call has been accepted 

y the called DTE by means of a call accepted 
packet. This places the specified logical channel 
in the data transfer state (p4). 


The time spent in the DTE waiting state (p2) 
will not exceed time-out T21]1 (see Annex D). 


Ae 36 Call- collision 


Call collision occurs when a DTE and DCE 
Simultaneously send a call request packet and an 
incoming call packet specifying the same logical 
channel. The DCE will proceed with the call 
request and cancel the incoming call. 


ages Clearing by the DTE 


The DTE may indicate clearing at any time by 
scum a clear request packet across the DTE/DCE 
a 


inter ce (see paragraph 4.5). The logical 
channel is then in the DTE clear request state 
(p6). When the DCE is prepared to free the 


logical channel, it will send a clear confirmation 
packet across the DTE/DCE interface specifying the 
proper logical channel. This jon teat channel is 
then placed in the ready state (p ys 


The DCE clear confirmation packet has only 
local significance, it does not affect calls 
outside the one logical channel cleared (such as 
end-to-end calls). The time spent in the DTE 


clear request state (p6) will not exceed time 
limit T23 (see Annex D)., 


It is possible that subsequent to sending a 
clear request packet and prior to the reception of 
a DCE clear confirmation packet, the DTE will 
receive other types of packets (depending of the 
state of the logical channel). 


The calling DTE may abort a call by clearing 
it before it has received a call connected or 
clear indication packet. 


The called DTE may refuse an incoming call by 
clearing it as described above instead of sending 
a call accepted packet. 


Ree lecs Clearing by the DCE 


The DCE will indicate clearing by 
transmitting across the DTE/DCE interface a clear 
indication packet (see 4.5). The logical channel 
is then in the DCE clear indication state (p7). 
The DTE shall respond by sending a DTE clear 
confirmation packet. The rok ae channel is then 
placed in the ready state (fl). 


The action taken by the DCE when the DTE does 
not confirm clearing within time-out T13 is given 
in Annex D. 


4.1.9 Clear collision 


Clear collision occurs when a DTE and DCE 
simultaneously send a clear request packet and a 
clear indication acket specifying the same 
logical channel number. When this happens, the 
DCE will consider the clearing completed and will 
not expect a DTE clear confirmation packet. The 
DCE will not send a DCE clear confirmation packet. 
The logical channel will be placed in the ready 
state (pl). 


Ae1e 0 


If a call cannot be established, the DCE will 
send a clear indication acket specifying the 
logical channel indicate in the call request 
packet to the calling DTE. 


Unsuccessful call 


4.1.11 Call progress signals 


The DCE wald. ‘be ‘capable :of Transfierriie to 
the DTE clearing progress signals as specified in 
a future document (AX.96). 


Clearing call progress signals will be 
carried in clear indication packets which will 
terminate the call to which the packet refers. 
The method of coding clear indication packets 
containing call progress signals is detailed in 
paragraph 6.2.3. 


4.1.12 Data transfer state 


The procedures for the control of packets 
between DTE and DCE while in the data transfer 
state are contained in section 4.3 below. 


4.3 Procedures for data and interrupt transfer 


The data transfer and interrupt procedures 
described in the following paragraphs apply 
independantly to each logical channel assigned for 
virtual calls existing at. the DTE/DCE interface. 


Normal network operation dictates that user 
data in data and interrupt poe are all passed 
transparently, unaltered through the network in 
the case of acket DTE to packet DTE 
communications. he order of bits in data packets 
is preserved. Packet sequences are delivered as 
complete packet sequences. Diagnostic codes are 
treated as described in sections 6.2.3, 6.5.3, and 
Ona xls 


4.5381 States for data transfer 


A virtual call logical channel is in the data 
transfer state (p4) after completion of call 
establishment and prior to a clearing or restart 
procedure. Data, interrupt!, flow control, and 
reset packets may be transmitted and received by a 
DTE in the data transfer state of a logical 
channel at the DTE/DCE interface. In. this state, 
the flow control and reset procedures described in 
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section 4.4 apply to data transmission on that 
logical channel to and from the DTE. 


When a virtual call is cleared, data and 
por aRs packets may be discarded by the network 
(see 4.5). In addition, data, interrupt, flow 
control, and reset packets transmitted by a DTE 
will be ignored ‘py the DCE when the lIogical 
channel is in the DCE clear indication state (p/). 
It is left to the DTE to define DTE to DTE 
protocols able to cope with various possible 
Situations that may occur. 


4.3.2 User data field length of data packets 
. The standard maximum usef data field length 
is 128 octets. 


The user data field of data packets 
transmitted by a DTE or DCE may contain any number 
of octets up to the agreed upon maximum... The user 
data field shall contain an integral number of 
octets. 


If the user data field in a data packet 
exceeds the maximum user data field length, the 
DCE will reset the virtual call with the resetting 
cause “Local procedure error”. 

4.3.3 Deliverv confirmation bit 

The setting of the Delivery Confirmation bit 
(D bit) is used to indicate whether or not the DTE 
wishes to receive an end-to-end acknowledgement of 
delivery of the packet with the D bit set. This 
acknowledgement is for data it has transmitted, 
and the acknowledgement is made using the packet 
receive sequence number P(R) (see 4,4 below Pp 


The use of the D bitdoes not obviate the 
need for a higher level protocol between 
communicating DTEs which may be used independantly 
of the D bit procedure to recover from user or 
network generated resets and clearings. 


4.3.4 More data mark 


If a DIE or DCE wishes to indicate a sequence 
of more than one packet, it uses the More Data 
Mark bit (M bit) as defined below. 


The M bit can be set tO one in any data 
packet. When it is set to one in a full data 
packet, or in a partially full data packet also 
carrying the D bit set to one, it indiactes that 
more data is to follow. Networks supporting AX.25 
will not perform data packet segmentation or 
recombination. 


A sequence of data packets with every M bit 
set to one except the last one will be delivered 
as a sequence of data packets with the M bit set 
to one except for the last one when the original 
pacreee having the M bit set to one are either 
ull (irrespective of the setting of the D bit) or 
partially full but have the D bit set to one. 

Two catgories of pees and B have been 
defined as shown in Table 6/AX.25. Table 6/AX.25 
also illustrates the networks treatment of the M 
and D bits at both ends of a virtual call. 


{ Data packet sent '! Data packet ! 
! by source DTE !! revd by the ! 
! i destination DTE! 
jCacesory ! mM ! D $!Full!! M ! D 
! B !Qorl !0 !Nof! 0 ! Oo ! 
| B ! 0 {lil !Nol!! 0 ! 1 ! 
! B ! 1 !i ! Nat! 1 ! 1 ! 
! B ! 0 fo ! Yes!! 0O ! Oo ! 

B ! 0 Ub. ts veal! 0 | 1 ! 

A ! 1 {oO ! Yes!! 1 0 ! 
| B ! 1 !1 ! Yes!! 1 | 1 ! 


Table 6/AX.25 
Definition of two categories of data packets 
and network treatment of the M and D bits 


4.3.5 Complete packet sequence 


A complete packet sequence is defined as 
being composed of a single category B packet and 
all contiguous preceeding category A packets 
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having the exact maximum user data field length 
with the M bit set. to one and the D bit set to 
zero. All other data packets are category B 
packets. 


When transmitted by a DTE source, a complete 
packet sequence is always delivered to the 
destination DTE as a single complete packet 
sequence. 


The user data field of the last packet of the 
sequence may have less than the maximum length and 
the M and bits are set as described in Table 


6/AX.25. 


Since the maximum user data field length is 
the same at both ends, the user data fields of 
data packets are delivered to the receiving DTE 
exactly as they have been received by the network. 
If the last packet of a complete packet sequence 
transmitted by the source DTE has a data field 
less than the maximum length with the M bit set to 
one and the D bit set to zero, then the last 


packet of the corrplete packet sequence delivered 
to the receiving, DTE will have the M bit set to 
Zero. 

4.3.6 Qualifier bit 


A complete packet sequence may be on one of 
two levels. If a DTE wishes to transmit on more 
than level, it uses the Qualifier bit (Q bit). 


When, only one, level of data is being sent on 
a logical chamnel, the Q bit is always set to 
zero. If two levels of data are being sent, the 
transmitting DTE should set the Q bit in all data 
packets of a complete packet sequence to the same 
value, either zero or one. A complete packet 
sequence, which is sent with the Q bit set to the 
same value in all packets, is delivered by the 
network as a complete packet sequence with the Q 
bit set in all packets to the value assigned by 
the transmitting DTE. 


When the Q bit is not set to the same value 
by the transmitting DTE within a comp lete packet 
sequence?, a network supporting AX.25 will reset 
the logical channel with the cause “Local 
procedure e ' -and a diagnostic code of 
Inconsistant Q bit setting”. 


Recommendation AX.29 gives an example of the 
procedures to be used when the Q bitiS set to 
one. 


Packets aré numbered ag pee ( (see 
4.4.1.1) regardless of their data level (Q bit 
setting). 

4.3.7 Interrupt procedure 


The interrupt procedure is used to allow a 
DTE to transmit data to the remote DTE without 
following the flow control procedure applying to 
data packets (see 4.4). The page oe procedure 
applies only in the flow control ready state (dl) 
within the data transfer state (p4). 


The interrupt procedure will have no effect 
on the transfer and flow control procedures 
applying to the data packets on a virtual call 
logical channel. 


To transmit an interrupt, the DTE sends a DTE 
interrupt packet across the DTE/DCE interface. 
The DTE should not send a second DTE ee aE 
packet until the first one is confirmed by the 
reception of a DCE interrupt conrirmation packet 
(see Note 2 to Table C-4/AX.25). After the 
interrupt procedure is completed at the remote 
end, the DCE will confirm the receipt of the 
interrupt by sending a DCE interrupt confirmation 
packet. The reception of a DCE interrupt 
confirmation packet indicates that the interrupt 
has been confirmed by the remote DTE by means of a 
DTE interrupt confirmation packet. 


The DCE indicates an interrupt from the 
remote DTE by sending a DCE interrupt packet 
across the DTE/DCE interface which contains the 
same data field as that in the DTE interrupt 
packet transmitted by the remote DTE. A DCE 
interrupt packet is delivered at or before the 
poe in the data packets stream at which the DITE 

nterrupt packet was generated. The DTE will 


confirm reception of the DCE interrupt packet by 
sending a DTE interrupt confirmation packet. 


4.4 Procedures for flow control 


Section 4.4 only applies to the data transfer 
state (p4) and specifies the procedures coverin 
flow control OE data packets and reset on each 
logical channel used for a virtual call. 


A Ae Elow Control 


The transmission of data packets across a 
DTE/DCE interface of a logical channel in a 
virtual call is controlled separately for each 
direction, and is based on authorization from the 
receiver. 


Flow control also allows a DTE to limit the 
rate at which it accepts packets across the 
DTE/DCE interface, noting that there is also a 
network-dependant timit on the number of packets 
ten may be within the network for the virtual 
Gall. 


A A eel al Numbering of data packets 
Bach data acket transferred across the 
DTE/DCE inter face for each direction of 


transmission in a virtual call is numbered 
sequentially. 


The sequence numbering scheme of the packets 
is in module The packet sequence numbers cycle 
through the entire range from zero to seven. The 

acket sequence numbering scheme is the same for 
both directions of transmission and is common for 
all logical channels at the DTE/DCE interface. 


Only data packets contain this sequence 
number, which is called the packet send sequence 
number P(S). 


The first data packet sent across the DTE/DCE 
interface for each direction of data transmission 
when the logical channel has just entered the flow 
control rea state (dl), will have a packet send 
sequence number equal to zero. 


4.4.1.2 


For each direction of a data transmission 
over a virtual call logical channel, a window is 
defined as the ordered set of W consecutive packet 
send sequence numbers of the data packets 
authorized to cross the interface. 


Window description 


The lowest sequence number in the window is 
referred to as the lower edge. When a virtual 
call at the DTE/DCE interface. has just entered the 
flow control ready state (dl), the window related 
to each direction of data transmission has a lower 
window edge equal to zero. 


The packet send sequence number of the first 
data packet not authorized to cross the interface 
is the value of the lower window edge plus W 
(module 8). 


The standard window size W is 2 for each 
direction of data transmission at the DTE/DCE 
interface. 


Ad. 1.3 Flow control principles 


When the sequence number P(S) of the next 
packet to be sent by the DCE is within the window, 
the DCE is authorized to transmit this data packet 
to the DTE. When the sequence number P(S) of the 
next data packet to be transmitted by the DCE is 
outside of the window, the DCE shall not transmit 
a data packet to the DTE. The DTE should follow 
this same procedure. 


When the sequence number P(S) of the data 
packet received by the DCE is the next in sequence 
and is within the window, the DCE will accept the 
data packet. A received data packet containing a 
P(S) that is out of sequence (such as when there 
is a gap in the received P(S) numbering, or a 
duplicate P(S) number), out of window, or not 
equal to zero for the first data packet after 
entering the flow control ready state (dl) is 
considered by the DCE as a local procedure error. 
The DCE will reset the virtual call (see 4.4.3). 
The DTE should follow the same procedure. 
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4.4.1.4 


4.4.1.5 


4.4.1.6 


A number (modulo S), referred to as a packet 
receive sequence number P(R), conveys across the 
DTE/DCE interface information from the receiver 
for the transmission of data packets. When 
transmitted across the DTE/DCE interface, a P(R) 
becomes the lower window edge. In this way, 
additional data packets mav be authorized by the 
receiver to cross the DTE/DCE interface. 


The packet receive sequence number, P(R), is 
conveyed in data, receive ready (RR), and receive 
not ready (RNR) packets. 


The value of a P(R) received by the DCE must 
be within the range from the last PR) received by 
the DCE up to and including the packet send 
sequence number of the next data packet to be 
transmitted by the DCE. Otherwise, the DCE will 
consider the reception of this P(R) as a procedure 
error and will reset the virtual call. The DTE 
should follow the same procedure. 


The receive sequence number P(R) is less than 
or equal to the next data packet sequence number 
expected, and .implies that the DTE or DCE 
transmitting P(R) has accepted at least all data 
packets numbered up to and including P(R)-1. 


Delivery confirmation 


When the D bit is set to zero in a data 
packet having P(S) equal to p, the significance of 
the returned P(R) corresponding to the data packet 
(ex. R)=pt+l) is a local updating of the window 
across the packet level interface so that the 
achievable throughput is not constrained by the 
DTE-to-DTE round trip delay across the network(s). 


When the D bit is set to one in a data packet 
having P(S)=p, the significance of the returned 
P(R) corresponding to that data packet (ex. 
P(R)=ptl) is an indication that a P(R) has been 
received from the remote DTE for all data bits in 
the data packet in which the D bit had originally 
been set to one. 


When a DTE receives a data packet with the D 
bit set. to ~one,; -at should. “transmit the 
corresponding P(R) as soon as possible in order to 
avoid the possibility of deadlocks (without 
waiting for further data packets). A data, RR, or 
RNR packet may be used to convey the P(R) (see 
Note to 14.1.6). Likewise, the DCE is required 
to send P(R) to the DIE as soon as possible after 
it is received from the remote DTE. 


In the case where a P(R) for a data packet 
with the D bit set to one is outstanding, the 
local updating of the window will be deferred for 
subsequent data packets with the D bit set to 
Zero. 


DTE -and_DCE_ receive ready (RR) packets 


RR packets are used by the DTE or DCE to 
indicate that it is ready to receive W data 
packets within the window oF er esne vee P(R), 
where P(R) is indicated in the RR pac:kt. 


DTE oS DCE receive not ready (RNR) 
Dack= 


RNR packets are used by the DTE or DCE to 
indicate a temporary inability to accept 
additional data packets for a given virtual cal.. 
A DTE or DCE receiving an RNR packet shall OP 
transmitting data packets on the indicated logica 
channel, but the window is updated by the P(R) 
value of the RNR packet. The receive not ready 
condition is cleared by the transmission in the 
Same direction of a RR packet or by a reset 
procedure being initiated. 


The transmission of a RR packet after a RNR 
packet at the packet level is not to be taken as a 
demand for retransmission of packets which have 
already been transmitted. 


The RNR packet may be used to convey across 
the DTE/DCE interface the P(R) value corrésponding 
to a data packet which had the D bit set to one in 
the case that additional data packets cannot be 


accepted. 


characteristics 


ut 


The attainable throughput on virtual calls 
carried at the DTE/DCE interface may vary due to 
the stastical sharing of transmission and switch 
resources and is constrained by: 

1) the access line characteristics, local window 
Size and traffic characteristics of other 
logical channels at the local DTE/DCE 

interface; 

2) the access line characteristics, local window 
Size and traffic characteristics of other 
logical channels at the remote DTE/DCE 
interface, and; 

3) the throughput achievable on the virtual 
call through the network(s) independant of 
interface characteristics including number of 
active logical channels. This throughput may 
be dependant on network service 
characteristics such as window rotation 
mechanisms and/or optional user facilities 
requested on national,international calls. 


The:, attainable will also be 


affected by: 
1) 
2) 


throughput 


the receiving DTE flow controlling tke DCE; 


the transmitting DTE not edgar data packets 
which have the maximum data field length; 

3) the local DTE/DCE window and/or packet sizes, 
and 3 


4) the use of the D bit. 


A throughput class for one direction of 
transmission a an inherent characteristic of the 
virtual call related to the amount of resources 
allocated to this virtual call. This 
characteristic is meaningful when the D bit is set 
to zero in data packets. It is a measure of the 
throughput that is not normally exceeded on the 
virtual call. However, due to the statistical 
sharing of transmission and switching resources, 
it is not guaranteed that the throughput class can 
be reached 100% of the time. 


Depending on the network and the applicable 
conditions at the considered moment, the effective 
throughput may exceed the throughput class. 


The definition of ete class as a grade 
of service parameter is for further study. The 
grade of service might be specified when the D bit 
is set to zero or over a time period between the 
completion and initiation of successive D bit 
procedures. 


The throughput class can only be reached if 
the following conditions are met: 


a) the access data links of both ends of a 
virtual call are engineered for the 
throughput class; 

b) the receiving DTE is not’ flow 
Controls ens the DCE such that the 
throughput class is not attainable; 

c) the transmitting DTE is sending data 
pee which have the maximum data 

ield length, and; 

d) all data packets transmitted on the 


virtual call have the D bit set to zero. 


The throughput class is epee eecd ini-bits per 
second. At the DTE/DCE interface, the maximum 
data field eee is specified for a virtual call, 
and thus the throughput class can be interpreted 
by the DIE as the number of full data packets per 
eons that the DTE does not have a need to 
exceed. 


The default throughput classes for both 
directions of transmission correspond to the user 
class of service of the DTE (see 7.4.2.6) but do 
not exceed the maximum throughput class supported 
by the network. 


The summation of throughput classes of all 
virtual calls supported at a DTE/DCE interface may 
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be greater than the data transmission rate of the 
access line. 

4.4.3 Procedure for reset 

The reset procedure is used to re-initialize 
the virtual cakl, and in so doing removes in each 
direction all data and interrupt packets which ma 

be in the network (see 4.5). When a virtual bald 
at the DTE/DCE interface has just been reset, the 
window related to each irection of data 
transmission has a lower window edge equal to 
zero, and the numbering of subsequent data packets 
to cross the DTE/DCE interface for each direction 
of data transmission shall start from zero. 


The reset procedure can only apply in the 
data transfer state (p4) of the DTE/DCE interface. 
it -any. ObhSr “state, . the reset procedure is 
abandoned. As an example. when a clearing or 
restarting procedure is initiated, reset requested 
and reset indication packets can be left 
unconfirmed. 


For flow control, there are three states (dl, 
d2, and d3) within the data transfer state (p4). 
They are flow control ready (dl), DIE. reset 
request (d2), and DCE reset indication (d3) as 
shown in the state diagram in Figure B-3/AX.25. 
When entering state p4, the logical channel is 
placed in state dl. Table B-4/AX.25 specifies 
actions taken by the DCE on the reception of 
packets from the DTE. 


4.4.3.1 


The DTE shall indicate a request for reset by 
transmitting a reset request packet specifying the 
logical channel. This places the logical channel 
in the DTE reset request state (d2). 


4.4.3.2 Reset indication packet 
The DCE shall indicate a reset sending to the 


DTE a _ reset indication packet specifying the 
logical channel and the_ reason for the resetting. 


Reset request packet 


This ‘places. the pop ee® channel in the DCE reset 
indication state (d3), In this state, the DC 
will ignore all data, interrupt, RR, and RNR 
packets. 

4.4.3.3 Reset Collision 


Reset collision occurs when a DTE and a DCE 
Simultaneously transmit a reset request packet and 
a reset indication packet specifying the same 
logical channel. Under these circumstances the 
DCE will consider the reset coumpleted. The DCE 
will not expect a DTE reset corfiirmation packet 
and will not transfer a DCE reset confirmation 
packet. This places the, logical channel in the 
flow control ready state (dl ). 


4.4.3.4 


When the logical channel is in the DTE reset 
request state (d27), the DCE will confirm reset by 
sending to the DIE a DCE reset confirmation 

acket. This places the logical channel in the 
Ficw control ready state (dl ). 

The reset confirmation packet has only local 
significance. The time spent in the DTE reset 
request state (d2) will not exceed time limit T22 
(see Annex D), 


Reset confirmation packets 


When the logical cahnnel is in the DCE reset 
indication state (d3), the DTE will confirm reset 
by transmitting to. Che. .DCEr a DIE. reser 
confirmation packet. This places the logical 
channel in the flow control ready state (dl). The 
action taken by the DCE when the DTE does not 
confirm the reset within time-out T12 is given in 
Annex D. 


4.5 Effects of clear, reset and restart 
procedures on the Eranster of packets 


All data and interrupt packets generated by a 
DTE (or the network) before initiation by the DTE 
or the DCE of a clear, reset, or restart procedure 
at the logical interface will either be delivered 
to the remote DTE before the DCE transmits the 
corresponding indication on the remote interface, 
or be discarded by the network. 


No data or Ue packets generated P| a 
DTE (or the network) after the cornpletion of a 
reset procedure at the local interface will be 
delivered to the remote DTE before the completion 
of the corresponding reset procedure at the remote 
interface. 


When a DTE initiates a clear, reset, or 
restart procedure on its local interface, all data 
and interrupt packets which were generated by the 
remote DTE (or the network before the 
corresponding indication is transmitted to the 
remote DTE will be either delivered to the 
initiating DTE before DCE confirmation of the 
initial clear, reset, or restart request, or be 
discarded by the network. 


The maximum number Se tas which may be 
discarded is a function of network end-to-end 
delay and throughput characteristics and, in 
general, has no relation to the local window size. 
For virtual calls on which all data packets are 
transferred with the D bit set to one, the maximum 
number of packets which may be discarded in one 


direction of transmission is not larger than the 
window size of the direction of transmission. 


i ee ee 


When a failure on the physical and/or link 
level is detected, the DCE will transmit to the 
remote end a clear with the cause "Out of order" 
for each existing virtual call. 


During the failure, the DCE will clear any 
incoming virtual calls with the cause "Out of 
order" and a diagnostic code of "Call setup or 
clearing problem". 


When the failure is recovered on the physical 
and link levels, the restart procedure will ‘be 
auctioned (see 3.5). 


5 Datagram service 


At this time, datagram service is not 
available in AX.25. 
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Description 


This papér is part two of a seériés. of papers 
that describe The Network Sublayer portion of an 
AX.25 data communications system. 


The purpose of this paper is to describe the 
formats of the various types of packets used to 
establish, maintain, and tear down a connection 
between a DTE and a DCE, along with the packets 
necessary to control the data flow along that 
connection while it is operational. 


This paper was generated by taking the CCITT 
X.25 document and adding or deleting information 
pertaining to amateur radio data networking. 


This isa first draft, corrections. and 
ammendments Gee be forthcoming. Follow the AMRAD 
Newsletter (see information in the first paper Of 
this series) for further information. 


6 Packet Formats 
6.1 General 


ete 


The possible extension of packet formats by 
the addtion of new fields is a subject for further 
study. In general any additional field would: 


a) only be provided as an addition following all 
ease gag defined fields, not as an 
ree hte etween any prevrously defined 

ields; 


b) be transmitted to a DTE only when either the 
DCE has been informed that the DTE is able to 
interpre’. this.-field and act’ accordingly, or 
when the DTE can ignore the field without 
adversely affecting the operation of the 
DTE/DCE interface; 


c) not contain any information pertaining to a 
user facility to which the DTE has not 
subscribed, unless the DIE can ignore the 
faci lary. without adversely affecting the 
operation of the DTE/DCE interface. 


Bits of an octe. are numbered. 8 ‘to 1 where 
bit 1 is the low order bit and is transmitted 
first Octets of a packet are consecutively 
ee starting at 1 and are transmitted in this 
order. 


Sele. General format identifier 


The general format identifier (GFI) field is 
a four bit binary coded field which is used to 
indicate the general format of the rest of the 
packet neades: The_ GFI is located in a 
ositions 6;and. 5-of: octet 1, with bit 
eing the ee order bit (see Table 7/AX. bs). 
Values for the GFI not specified in Table 7/AX.25 
are reserved for future use. 


Bit 8 of the GFI is used for the Qualifier 
bit (Q bit) in data packets, and is set to 0 in 
all other packets. 


Bit 7 of the GFI is used for delivery 
confirmation (D bit) in data packets. It is set 


to 1 in call set-up packets, and is set toOin 
all other non-data packets. 


Bits and 5 are encoded O and 1 
respectivel ‘y, indicating that all sequence 
numbering will be done modulo 8. The encoding of 
bits 6 and_5 to_1 and 0 is reserved for future 
use. Bit 6 and 5 encodings of both zero or both 
one are not allowed under this recommendation. 


General Format Identifier (GFI) ! Octet 1! 


; bits ! 

18765 ! 
! Call set up packets 10101! 
ee eee eee ee et ee rr | ee | 
i Clearing, flow control, ! ! 
. interrupt, reset, restart, 1o0o0ol1! 
; and diagnostic packets 
| Data packets 1xxol! 


a bit marked X may be either a 0 or al as 
indicated elsewhere in the text. 


Table 7/AX.25 
General Format Identifier 


Gel eZ Logical channel group number 


The Logical channel group number (LCGN) is in 
all packets except for restart or diagnostic 
packets. qj 1$ prey encoded, and resides in bit 

ositions 2, and 1 of octet Ty. WoL. bade: al! 
heitie See a order bit. For each logical 
channel, this number has local significance at the 
DTE/DCE interface. 


In restart and diagnostic packets the logical 
channel group number is set to all zeros. 


Dl a3 Logical channel number 


The logical channel number (LCN) is in all 
packets except for restart or diagnostic packet!. 
Tt is biimary encoded. and resides in all bit 
positions Ofoctet 2, with bit 1 being the low 
order bit. For each logical channel, the LCN has 
local significance at the DTE/DCE interface. 


In restart and diagnostic packets the logical 
channel number is set to all zeros. 


6.1.4 Packet type identifier 


Each packet type will be identified by the 
encoding “of. ecter Of .the packet . This 
identifier takes all bit positions, and_is encoded 
as shown in Table 8/AX. 95° (Table 8/AX.25 is at the 
end of this paper). Packet type_identifiers gene 
than those shown in Table 8/AX.25 are reserved. 


6.2 Call. set-up and. ‘clearing ‘packets 


Ge Gul, Call request and incoming call packets 


Figure 1/AX.25 illustrates the format of call 
request and incoming call packets. 


3.30 


Bit Position 


8 7 6 5 3 2 1 
1 ! General Format ! Logical Channel ! 
! mur ier (GFI) ! Group Number ' 
0 00 1 1 t (cen) : 
Cc She en een toe waweeeeneo 2&2 2 fF ££ F& = © - tal 
7 2 iseieal channel Number (LCN) 
T ' Packet Type Identifier t 
31 0 0 0 0 1 0 a al 
! Calling DTE | Called DTE | 
4 = Address Length ! Address Length 
vO DTE Addresses 
ca (see Note,] ee ee 
! ! Oe: 2h O*. = 36 
0 oO! Facility Length | 
| mm mounae =a om a aS aeeoqeeanawaeen ewe ewe eaeaes & see a" 
V 
A! Facilities 
R 
si gab Call User Data | 
A | (see Notes 2 and 3) 
R-! 

Note l The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field as. potentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 

Note 2. Bits 8and 7of the first octet of the 
call user data field may have particluar 
Significance (see 6.2.1). 

Note 3. Maximum length of the call user data 


field is 16 octets. 


Figuie 1/AX.25 
Call request and incoming packet format 


Oa 2s del General format identifier 

Bit 8(Q bit) shall be set to 0, bit 7 (D 
bit) shall be set i 1, and bits 6 and 5 should be 
set to 0 and 1 respectively. 
Oe2e bl eZ Address lengths field 


Octet 4 consists of field length indicators 
for the called and calling DTE address fields. 


Bits 4, 8, 2, and 1 indicate the called DTE 
address leng:zh in semi-octets (nibbles)). Bits 8, 
7, 6, and indicate the calling DTE address 


length in nibbles. Each address length indicator 
is encoded in binary, with bits 1 and 5 being the 
low order bits of their respective indicators. 


622s Address field 


Octet 5 and the oe Ow Ene octets (up to 32 
octets) consist of the called DTE address, 
followed by the calling DTE address. These 


addresses are encoded as described in Annex F. 
6.2.1.4 


The octet. following the DTE address fields 
contains the facility length field. This octet 
has bits 8and 7 unassigned, and both are set to 
Os Bits-6;5,. 4). 3). 2y-and 1 contain the facility 
length information. This information is binary 
coded, with bit 1 being the low order bit. 


ee elas 


Facility length field 


Facility field 


The facility: field is .present.-only when the 
DTE is using an optional user facility requiring 
some indication in the call request and incoming 
call packets. 


The coding of the facility field is described 
in section 7. 


The facility field must contain an_integral 
number of octets. The actual maximum length of 
this field depends on the facilities which are 
offered by the packet switch and network. The 
maximum number must not exceed 63 octets at any 
time. 


3.31 


OxZa 50 


A call user data field may be present 
following the facilities field. This field may be 
up to 16 octets long, and must contain an integral 
number of octets. 


Call user data field 


Tia call user data tield is: present, “the use 
and format of this field are determined by bits 8 
and 7 -oF “Ehe “ars octet. of “this: f£reld’ ~an 
accordance with the following: 


If bits 8and 7are 00, 
user data field is 
identification in accordance 
Recommendations (such as AX.29). 


a portion of the call 
used for protocol 
with other 


If bits 8 and 7 are set to 01, a portion of 
the call user data field may be used for 
protocol identification in accordance with 
specifications of networks. 


If bits 8 and 7 are 10, a portion of the call 
user data field may beused for protocol 
identification in accordance with 
specifications of international user bodies. 


If bits 8 and 7 are set to 11, no constraints 
are placed on the use by the DTE of the 
remainder of the call user data field. 


Users are cautioned that if bits 8 and 7 have 
a, value other than.11, -a “protocol may be 
identified that is implemented within the network. 


When a virtual call is established between 
two packet mode DTEs, the network does not act on 
any part of the call user data field. 


6.2.2 Call accepted and call connected packets 


Figure 2/AX.25 illustrates the format of call 
accepted and call connected packets. 


Bit Position 
5 4 3 


Logical Channel ' 


| 

General Format | ! 
Group Number 
! 

| 


t rear (GFI) ! 
Bo 0. a 1! cy 


HEYWaQO 
IN) 


! Calling DTE | Called DTE ! 
Address Length | Address Length 
DTE Addresses 

(see Note 1) 


qe eee new aese wn enmaeaeannases. 


Desa 


Facilities ! 
(see Note 2) 


Des 


The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field aS eee of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 


The facility field is not mandatory in 
call accepted packet (see 6.2.2). 


Figure 2/AX.25 
Call accepted and call connected packet format 


ee re ore General format identifier 
Bit 8(Q bit) shall be set to 0, bit 7 (D 
bit) shall be set to l, and bits 6 and 5 should be 
set to 0 
6.22.52 
Octet 4 consists of field length indicators 


for the called and calling DIE address. fields. 
Bits 4, 3, 2, and 1 indicate the called DTE 


Note 2. 


and 1 respectively. 


Address lengths field 


address leng:h in semi-octets (nibbles). Bits 8, 
7, 6, and indicate the calling DTE address 
length in nibbles. Each address length indicator 
is encoded in binary, with bits 1 and 5 being the 
low order bits of their respective indicators. 


cat re ene: Address field 


Octet 5 and the poLTow ine octets (up to 32 
octets) consist of the called DTE address, 
followed by the calling DTE address. These 
addresses are encoded as described in Annex F. 


Gage e4 


The octet following the DTE address fields 
contains the facility length field. This octet 
has bits 8 and 7 unassigned, and both are set to 
O. “Birks 6:5, 25.3). 2). and 1 contain the facility 
length information. This information is binary 
coded, with bit 1 being the low order bit. 


Facility length field 


The use. -or the tacility lTength: field. ‘in call 
accepted packets is mandatory. It should be set 
to all zeros if there is no facility field. 


Ox 242.0 


The facility field is present only when the 
DTE is using an optional user facility ect ae 
some indication in the call accepted and cal 
connected packets. 


Facility field 


The coding of the facility field is described 
in section 7. 


The facility field must contain an integral 
number of octets. The actual maximum length of 
this field depends on the facilities which are 
offered by the packet switch and network. The 
maximum number must not exceed 63 octets at any 
time. 


Gu253 Clear request and clear indication 


packets 


Figure 3/AX.25 shows the format for clear 
request and clear indication packets. 


! General tonne: ' Logical Channel ! 

0 1 !Identifier (GFI) 0! Group Number ! 
rawn wot 

Cc ! awaeeweecaewrnwroaeee @2ee ere eee = - = = = -= = - ~ ft 

y 2 !____Logical Channel Number (LCN) 3 
ny Packet Type 

Recetas Ol eases eveteen si ical 

f 0 U ' 

4! Clearing Cause ; 

i Diagnostic Code 


Figure 3/AX.25. 
Clear request and clear indication packet format 


Grd woe 


Octet 4 is the clearing cause field, which 
contains the reason for the clearing of the call. 


Clearing cause field 


In clear request Pech eee the clearing cause 
field should be set by the DTE to one of the 
following values: 


bits BP 6235 4.. 332-1. 

valuel: 00000000 

value2: 1XXxXxXKXXX 
where X may be either 0 or 1 


The DCE will prevent values other than those 
specified above in the clearing cause field from 
reaching the other end of the call by considering 
the clear request as an error and following the 
procedure described in Annex C 


The. coding “ot. the. clearing cause-freld an 
clear indication packets is given in Table 
9/AX.25 (Table 9/AX.25 is at the end of this 


paper). 


Ou oak Diagnostic code 


Octet 5 is the diagnostic code which contains 
additional information on the reason for the 
clearing of the call. 


In a clear request packet, the diagnostic 
code is not mandatory. 


In a clear indication packet, if the clearing 
cause field indicates "DTE originated", the 
diagnostic code is passed unchanged from the 
clearing DIE. if. the clearing DIE: has not 
provided a diagnostic code in its clear re ee 
packet, then the bits of the diagnostic ane cb 
the resulting clear indication packet will all b 
zero. 


When a clear indication packet results from a 
restart request packet, the value of the 
diagnostic code will be that specified in the 
restart request packet, or all zeros in the case 
where no diagnostic code has been specified in 
restart request. 


When the clearing cause field does not 
indicate "DTE originated , the diagnostic code in 
a clear indication packet is network generated. 
Annex E lists the coginee for network generated 
diagnostics. The bits of the diagnostic code are 
all set to zero when no specified additional 
information for the clearing is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field.. A DTE 
is not required to undertake any action on the 
eontents of. the. diagnostic (code: ..-treld, 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.2.4 DTE and DCE clear confirmation packets 


Figure 4/AX.25 shows the format of the DTE 
and DCE clear indication packets. 


Bit 
Sb S aden cee | eos ened eee cates 
1 ! GeneralGFoumat | LNginiedr Channel i 
0 ! | Identifier ae ! ci 
Cc (etitsewtocwcosecweeeet, we aie ee ae 
a 2! Logical Channel Nunber (LCN) : 
ah 


Figure 4/AX.25 
DTE and DCE clear confirmation packet format 


6.3 Data and interrupt packets 
peeral DTE and DCE data packets 


Figure 5/AX.25 illustrates the format of the 
DTE and DCE data packets. 


Bit Position 
5 4 


o.- 6 2 1 
! General Format ! Logical Channel ! 
! Identifier (GFI) ! Group Number ! 
0) ! Q Dd O £2 ! 
C fone e nen n nee nene neem ew me eee eee el! 
T ! Logical Channel Number (LCN) 
EK. y, seer ree si ees ree ans Seer e ese erSeeeeS= ! 
A ! P(R) i ae P(S) !0 : 
Vv ; ! 
A User Data 
R : 
Where: D is the Delivery confirmation bit 


M is the More data bit 
Q is the data Qualifier bit 


Figure 5/AX.25. DTE and DCE data packet format 


3.32 


(Q) bit 


Bit 6 “of octet. 1 
© bit. operation 


6.3.1.1 Qualifier 


is the qualifier bit (Q 
bit). is described in section 


AD 80% 
ere ee 
Bit 7 of octet 1 is the delivery confirmation 


bit (D bit). D bit operation is described in 
section 4.4.1.4. 


Delivery confirmation_(D) bit 


eee are een) Packet receive sequence number 


7, and 6 of octet 3 are used for 
indicatin the packet receive sequence number 
P(R). PCR) is binary coded with bit 6 being the 
low order bit. 


Bits 8, 


6.3.1.4 More data bit 


Bit 5 in octet 3 is used for the More data 
mark (M bit); 0 for no more data, 1 for more data, 


04, Oct ao) Packet send sequence number 
Bips: 2, Sy and 2 -oOF- Cehet:. 3: care: used, tor 


indicating the packet send sequence number P(S). 


P(S) is binary coded, with bit 2 being the low 
order bit. 
O52 dix User data field 

Octets following the third octet contain user 
data. The user data field must contain an 
integral number of octets. 
b.902 DTE and DCE interrupt packets 


Figure 6/AX.25 illustrates the format of the 
DTE and DCE interrupt packets. 
Bit Position 


General Format | Logical Channel 


! ! 
1! Identifier (GFI) ! Group Number ! 
0 ! 0 0 0 1 ! 
Cc ia ge a ete et dp a a ee ee oe we ewe e2# 2e©® 2 # & @ | 
T 2.4 Logical Channel Number (LCN) ! 
EB fee meen eee enc c ewe ewe e rr essen er ccreccen | 
T ! Packet Type Identifier | 
ae Ww) ae re 
aa al a ad ! 
4! Interrupt User Data ! 
Figure 6/AX.25. 
DTE and DCE interrupt packet format 
bs Salk Interrupt user data field 
Octet 4 contains user data. 
Ooo DTE and DCE Interrupt _confirmation 
==. ~ packets. © 0 Se ee 


Figure 7/AX.25 illustrates the format of the 
DTE and DCE interrupt confirmation packets. 


Bit a a 


—— — meee ee eee sem 


! General Format | Logical Channel 


1 ! Identifier (GFI) Group Number 
0 ! 0 0 0 : ie 
Co lawn eeenneenee------- -- tse ee ee 
T 24 Logical Channel Number (LCN) ! 
E | mem mme mem m ewer nen ree eee ener essen eann 
7 ! Packet Type Identifier 

a 0) aCe 


Figure 7/AX.25 
DTE and DCE interrupt confirmation packet format 


6.4 Datagram _and datagram service signal packets 


Datagrams are not implemented in AX.25. 


6.5 Flow control and reset packets 


DTE and DCE receive ready (RR) packets 


Figure 10/AX.25 shows the format of the DTE 
and DCE receive ready (RR) packets. 


3.33 


i A a eA tae fp Sess a i a a a a Ce a Fe ae 


! General Format | Logical Channel ! 


1! Identifier (GFI) ! Group Number | 
0 ! gr na xa) al , 0 ! 
C ' aeaweweeweee ew @@ wee eee ee = = - - bal - - = ae 1 
Z 2! Logical Channel Number (LCN) | 
Shei ote wae tpeg tail 
T ! ! PacketO Typ@ Id@ntifier 
cae P(R) 
re 10/AX.25 
DTE shar E RR packet format 
by Scellail Packet receive sequence number 
Bits 8, 7, and 6 of octet 3 are used for 
BTR P(Re the packet receive sequence number 
P(R). P(R) is binary coded, with bit 6 being the 
low order bit. 
6522 DTE and DCE receive not ready (RNR) 


ackets 


Figure 11/AX.25 illustrates the format of the 
DTE and DCE RNR packets. 


Bit Position 


8 7 6 D 3 2 a 
1 ! General Format ! Logical Channel ! 
! Identifier (GFI) ! Group Number ! 
0 ! 0 oO 0 Ee! ! 
Cc lame wonneueranne e@gae a noe @ - _ = - - Load > = ! 
Tt. 2 Logical Channel Number (LCN) ! 
E Se eran es BF eee eeenwaenevwewemens eee wewaeeeoaeeecenn a eee ! 
T ! ! Packet Type Identifier ! 
34! P(R) ! 0 0 10 1 ! 
Figure 11/AX.25 
DTE and DCE RNR packet formats 
bowel Packet receive sequence number 
Bits 8, 7, and 6 of octet 3 are used for 
indicatin the packet receive sequence number 
P(R). P(RY is binary coded, with bit 6 being the 
low order bit. 
Owes Reset: request: and eset. indication 
packets aSSS 


Figure 12/AX.25 illustrates the format of the 
reset request and reset indication packets. 


Bit Position 
4 


8 f 6 2 ff 

! General Format . ! Logical Channel ! 

1! Identifier (CFI) ! Group Number ! 

0 ! 0 0 O 13 (LCGN) 
C fewer mormon een nen nnnn= “ref e “2-7 2 ! 
ae es oe Channel Number (LCN) ! 
T ! Packet Type Identifier { 
3 } Oo 860 ae, dt. ot ! 
{aan aooe a2 ema wan euvean ana naanZreoanwoanenaenwanae ! 

4! Resetting Cause ! 

Ym wm ww en ne nnn ne senes ! 

5 ! Diagnostic Code ! 


Figure 12/AX.25 
Reset request and reset indication packet format 


Resetting cause field 
Octet 4 is the resetting cause field, which 
contains the reason for the reset. 


the resetting cause 


In reset request packets, 
DTE to one of the 


field should be set by the 
following values: 


bite Bee ae Yas Se Di 
valuel: G0 Or OO BO 0 
value2: L KK XK KH KX 


where X may be either 0 or 1 


The DCE will prevent values other than those 
specified above in the resetting cause field from 
reaching the other end of the call by considering 


the reset request as an error and following the 
procedure described in Annex C. 


The coding of the resetting cause field in 
the reset indication packets is given in Table 
11/AX.25 (Table 11/AX.25 Is at the end of this 


paper ). 


6.5.3.2 Diagnostic code 


Octet 5 is the diagnostic code which contains 
additional information on the reason for the 
reset. 


In a reset. indication acket, if the 
resetting cause field indicates “PTE originated”, 
the diagnostic code is pares unchanged from the 
resetting DTE. If the D requesting a reset has 
not provided a diagnostic code in its reset 
re uest packet, then the bits of the diagnostic 
co8e in the resulting reset indication packet will 
all be zero. 


When a reset indication packet results from a 
restart request packet, the value of the 
diagnostic code will be that specified in the 
restart request packet, or all zeros in the case 
where there is no diagnostic code has been 
specified in restart request packet. 


When. the resetting cause field does not 
indicate "DTE originated’, the diagnostic code in 
a reset indication packet is network generated. 
Annex E lists the codings for network generated 
diagnostics. The bits of the diagnostic code are 
all set to zero when no specified additional 
information for the reset is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field. A DTE 
is not required to undertake any action on the 
Contents. “Of. the: ‘diagnostic code. tield. 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.5.4 


Figure 13/AX.25 shows the format of the DTE 
and DCE reset confirmation packets. 


BitPosition 
5 4 


DTE and DCE reset confirmation packets 


8 7 3 2 1 


! General Format ! Logical Channel ! 
' up une E 
ede 3g 3E 


0 ! Tdaptifjer | (Any) GN) 
C Pewee eee ene enennnne ~e &® wee eee a « ! 
rT: 4 : Logical Channel Number (LCN) 
EB é See een ewe enaeneeaana ® See we eS eeanwnensae eg ee aa et 
TL ! Packet Type Identifier ! 
3! 0 0 1 1 1 41 ! 
Figure 13/AX.25 
DTE and DCE reset confirmation packets 
6.6.1 


aCKeUs 


Figure 14/AX.25 illustrates the format of the 
restart request and restart indication packets. 


Bit Position 
5 4 3 


SO elise Ot Se ad 2 Aik. 

! General Format | ! 

1! Identifier (GFI) ! ! 

0 0 0 0 1 ! 0 0 0 0 
Ce lewenesenwecaeanecece owe ewe @ @ © @ © © @ 

T 2-1 0) 0) 0 O 0 0 0) 0) ! 

E Joe mm nm mmm new ne nn nnn wen ewe eee conecnceen| 

nn ! Packet Type Identifier | 

3 1 1 1 o 1 1 

4 ! Restarting Cause ! 

5! Diagnostic Code | 


Figure 14/AX.25 
Restart request and restart indication 
packet format 


6.6.1.1 


Octet 4is the restarting cause field, which 
contains the reason for the restart. 


Restarting cause field 


Restart request and restart indication 
Packets 


3.34 


In restart request packet 
cause field should be set by the 
following values: 


r 
TE to one of 


bitt 87654321 
valuel: 00000000 
value2: 1XXXXXXKX 
where X may be either 0 or 1 


The DCE will prevent values other than those 
specified above in the restarting cause field from 
reaching the other end of the Call by considering 
the restart request as an error and Following the 
procedure described in Annex C 


The coding of the restarting cause field in 
the restart indication packets is given in Table 
12/AX.25. 


ee ee ee ee JIBS Bie Do aS 
! Local procedure error 100000001 T 
! Network congestion 100000011 ! 
|! Network operational !00000111 ! 


Table 12/AX.25 
Coding of the restarting cause field 
in restart indication packets 


Octet 5 is the diagnostic code which contains 
additional information on the reason for the 
restart. 


The diagnostic code is passed to the 
corresponding DTEs as the diagnostic code of a 
clear indication packet for virtual calls. 


Diagnostic code 


The coding in a restart indication packet is 
given in Annex E. The bits of the diagnostic code 
are all set to zero when no specified additional 
information for the restart is supplied. 


The contents of the diagnostic code field do 
not alter the meaning of the cause field. A DTE 
is not required to undertake any action on the 
contents of the diagnostic code field. 
Unspecified code combinations in the diagnostic 
code field shall not cause the DTE to refuse the 
cause field. 


6.6.2 DTE and DCE restart confirmation packets 
Bit Position 
8 7 6 5 4 3 2 1 
! General Format | ! 
1! Identifier (GFI) ! | 
0) 0 0 0 1 ! 0 0 0 0 
SG Se ean ee eananaeonan ane ene = = -= = Ce ee 
H 2 0 0 0) 0) 0) @) 0) 0) 
T ! Packet Type Identifier ! 
3! 1 1 1 1 1 1 $ 


Figure 15/AX.25 
DTE and DCE restart confirmation packet format 


6.7 Diagnostic packet 


Figure 16/AX.25 shows the format of the 
diagnostic packet. 


8 7 6 Bft Position3 2 1 


! General Format } 


| 
1! Identifier (GFI) ! 0 0 0 0 ! 
Oo ! 0 oO QO 1 ! 
Cc | -----~-------------- - - ++ - ----! 
z 2 0 0 0 0 0 0 O 0 ! 
T ' Packet Type Identifier 
3 | 1 1 0 0 0 1 
! Diagnostic Code 
5 ! Diagnostic Explanation (see Note 1) ! 
Note 1: The figure drawn assumes an integral 


number of octets in the diagnostic 
explanation 


Figure 16/AX.25 Diagnostic packet format 


Diagnostic code field 


Octet 4 is the diagnostic code and contains 
information on the error condition that caused the 
transmission of the diagnostic packet. The coding 
of the diagnostic field is given in Annex E. 


OolsZ. Diagnostic explanation field 


When the diagnostic packet is issued as a 
result of the reception of an errgneous packet 
from the DIE (see Table C-1/AX.25), this field 
contains the first three octets of header 
information from the erroneous DTE packet. If the 
packet Contains less Chan 3° octets; this ‘field 
contains whatever bits were received. 


When the cae nee ete packet is issued as 
result of a DCE time-out (see Table D-1/AX. 25), 
the diagnostic explanation field contains 2 octets 
coded as follows: 


bites "ey. J, “6y- <nd: -5- oF the: Pirrst. octet 
contain the general format identifier for the 
interface; 


bits 4 to 1 of the first octet and bits 8 to 
1 of the second octet are all zero for the 
expiration of time-out T10 and give the 
number of the logical channel on which the 
time-out occured for expiration of time-out 
T12-0r T13% 

2 


6.6. 


acceptance facility — 

omoiee ape 

Figure 18/AX.25 illustrates the format of 

call request and beens oe Cate packets used in 
as 


conjunction with the select facility 
described in section 7.2.4. 


Call request and incoming call packets 


The description in section 6.2.1 applies 
except that the length of the call user data 


here, 
and 


field has a maximum length of 128 octets, 
should contain an integral number of octets. 


Bit Position 
5 4 3 


sia ta ee ee a 
1 ! General Format ! Logical Channel ! 
! Identifier (GFI) ! Group Number ! 
0 ' oOo 1 0 1 =! (LCGN) 
C Pemmme were wner eer nes eee er tee 
T 2 Logical Channel Number (LCN) ! 
E aa ala Nl li ! 
T ‘ ‘ Packet Type Identifier : 

listestestentantententeeteetetententeniententententenentententententeneatentetestcateetemtateteateteteten | 

! Calling DTE ! Called DTE | 

4 ! Address Length ___! Address Length | 

‘an DTE Addresses | 

A! (see Note 1) 

Ro AER REESE 5£---J--------- 
fate at ec uti tt comes SOEs NO et On oe 
| 0 Ce Facility Length 
(Gise OS e cca Seen eo an daa a sano a alae's's oma ] 

V 

Aud Facilities 

R 
pete222222 223525 ee eee eee 

v I Call User Data 

A (see Notes 2 and 3) 

R! 

Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field is potentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 

Note 2. Bits 8 and 7 of the first octet of the 
call user data field ma have particluar 
Significance (see 6.2.13, 

Note 3. Maximum length of the call user data 


field is 128 octets. 


Figure 18/AX.25 
Call request and incoming call packet format 
for the fast select facility 


set-up and clearin ackets for t he 
fastecteFactlity and fast select —{_ 


3.35 


Call accepted and call. connected 


Geez 
-packetsS” 


Figure 19/AX.25 illustrates the format of 
call accepted and call connected packets used in 
conjunction. with the fast Select Facility 
described in section 7.2.4. 


Bit Position 
5 4 3 


! General Format | Logical Channel 


! 
1 ! Identifier (GFI) ! Group Number ! 
0 af ga tt [aA 4.1 of ( ) } 
C | ---- ne ene nee ew ee ee ee ee! 
T° Logical Channel Number (LCN) ! 
E | en en ee ee ee eee een nen ! 
T ! Packet Type Identifier ! 
3°. 0 1 ! 
here eee Rae Sar aaa ! 
! Calling DTE Called DTE | 
Pe peochers eUgen id | Address Length _ ! 
V DTE Addresses 
A! (see Note 1) | 
R @gQqje eFeweeqeee &» mene we eee ee 
: 0 0 0 0 
| 0 Ore! Facility Length ! 
si ! 
A! Facilities 
R | 
(eee Beet eee ee eee tie Seles 
Call User Data 
(See Notes 2 and 3) 

Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub-field is potentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 

Note 2) (Bits: :3. and J of the first octet of the 
call user data field eee have particluar 
Significance (see 6. 

Note 3. Maximum length of the call user data 


field is 128 octets. 


Figure 19/AX.25 
Call accepted and call connected packet format 
or the fast select facilitp 


The description in section 6.2.2 applies 
here. In addition, a call user data field may be 
present. If a calf user data field is present, it 
can contain up to a maximum of 128 octets, and 
must contain an integral number of octets. 


Tt a Call user date field-is present. the use 
and format of this field are determined by bits 8 
and 7 of the first octet of this field in 
accordance with the following: 


If: bits. 8 and / are 00, «a portion of ‘the call 
user data field is used for protocol 
identification in accordance with other 
Recommendations (such as AX.29) 


If bits 8 and 7 are set to Ol, portion of 
the call ‘user Cate. field may Be used for 
protocol identification in accordance with 
specifications of networks. 


If bits 8 and 7 are 10, a portion of the call 
user data field may ‘be used for protocol 
identification ain accordance with 
specifications of international user bodies. 


If bits 8 and 7 are set to 11, no constraints 
are placed on the use by the DTE of the 
remainder of the call user data field. 


Users are cautioned that if bits 8 and 7 have 
a value other than 11, a protocol may be 
identified that is implemented within the network. 


When a virtual call is established between 
two packet mode DTEs, the network does not act on 
any part of the call user data field. 


6.05269 Clear request and clear indication 


packets 


Figure 20/AX.25 illustrates the format of 
clear request and clear indication packets used in 
conjunction with the fast select facility and fast 
Ss otis ae a facility described in sections 

an 


Bit Position 
5 4 3 


! General Format | Logical Channel 
1 ! Identifier (GFI) ! Group Number 
0 0 0 1! (LCGN) 


Logical Channel Number (LCN) 


y Packet Type Identifier | 
0 oO 1 0 oO 1 ! 


HEWQ0 
NO 


! Clearing Cause 


! Diagnostic 


Called DTE | 
-Length-.-! 


O1 


{ Calling DTE ! 
laddress lenoth.d. 
DTE Addresses 


(see Note }) ae 


| ee en 


Facility Length ! 


Des on 


P< 
| 
eb) 
Q 
LH. 
Ju 
I 
ct 
LE 
0) 
0) 


Call User Data 


J a eet (See Note 2) 00 : 


Note 1. The figure is drawn assuming the total 
amount of address information is not an 
integral number of octets. Each address 
sub field 25, pocentially of variable 
length, any padding necessary is added at 
the end, and will consist of zeros. 


Note 2. Maximum length of the call user data 
field is 128 octets. 


Figure 20/AX.25 
Clear request and clear indication packet format 
for the fast select facility and_clear indication 
packet format to the calling DTE for the called 
called line address modified notification facility 


The descriptions of the clearing cause field 
and the diagnostic code field in section 6.2.3 


eae ae et In additiion, the following fields 
may follow the diagnostic code field (the use of 
the diagnostic field itself is mandatory). 
6.8.2.3.1 Address length field 

This field is coded with all zeros. 
6.8.2.3.2 Address field 

This field is not present. 
6.8.2.3.3 Facility length field 


This field is coded with all zeros. 


6.8.2.3.4 Facility field 


This field is not present. 


6.8.2.3.5 Clear user data field 


Following the facility field, a clear user 
data field may be present, and if present, it may 
be up to a maximum of 128 octets. The clear user 
data field is required to contain an integral 
number of octets. 


6.8.4 Clear indication packet Tor talled line 
address moditied notification facility 


Figure 20/AX.25 illustrates the format of 
clear indication packet used in conjunction with 
the called Jane address modified Poet 
facility described in section 7.2. 


The large EAON In SSCE10n, "6. 8.233; Spplies 
here, except e eye attached to sections 
2G. eb and e: G2 .3<5: and. al of Sections 
6,052,362; (6. 05 2.8.4; | O. One eo o's 


Address field 


The “addess: iield ws present “only when ithe 
call is redirected and then cleared by the network 
or by the alternate DTE without the transmission 
of the call accepted packet. It consists of the 
alternate DTE address. 


The coding of the address field is described 
in section 6.2.1.3. 


Facility field 


The facility field is present on¥ when the 
call is redirected and then cleared by the network 
or b toe alternate DTE without the transmission 
Or 3 call accepted packet. 


The coding of the facility field is defined 
in section 7. 
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Fram_DCE_ta_DTE | 


Call set-up and clearing 
! Incoming call | 
Call connected 


Fram _DTE ta DCE 


Call request 
Call accepted 


! Clear indication | Clear request 
! DCE clear ! DTE clear 
confirmation | confirmation 

| Data and interrupt 

! DCE data ! DTE data 

! DCE interrupt ! DTE interrupt 
{ DCE interrupt ! DTE interrupt 
! confirmation 
! Flow control and reset 

! DCE RR ! DTE RR 

! DCE RNR ! DTE RNR 

! Reset indication ! Reset request 
! DCE reset | DTE reset 
confirmation ! confirmation 
! Restart 

! Restart indication ! Restart request 
' DCE restart ! DTE restart 

| confirmation | confirmation 
| 

| Diagnostic 

! Diagnostic 


Table 8/AX.25. 


! Bits ! 

87654321 

! DTE originated '00000000! 

{ DTE originated (b) FP xxx xxx x! 
| Number busy 100000001! 
| Out of order 1roo0o00o0100d1! 
! Remote procedure error froo0oo01ld0dd0l! 


1 Network con 0 
! Not obtainable ! oO 
! RPOA out-of-order (a) ! 0 


! Reverse charging acceptance !00011001 ! 
not subscribed ! | 
! Incompatible destination ! 
Fast select acceptance ! 
| not subscribed ! 
! Destination ! 


! Invalid facility request 0 
| Access barred ! 0 
! Local procedure error 0 


absent 


estion 


(a) 


(b) 


May be received only if the corresponding 


optional user facility is used. 


When bit 8 is set to 1, the bits 
represented by Xs are those included by 
the remote DTE in the clearing or 


restarting cause field of the clear or 
restart request packet. 


(d) Used for amateur to public data network 


internetworking only. 


Table 9/AX.25 


Coding of clearing cause field 
in clear indication packet 


an x bit may be either a 


Packet type identifier 


! Octet 3 Bits 


bo owe bobo toes a2elet 
! 

! ! 
‘oo0ooltol1il1! 
‘oo0odilil! 
'oo0o0l00d11! 
: 00010111 
' { 
! ! 
!'xxxxxxx0O0! 
‘roo0oloootll1! 
; OoO01l1lOl1tLI!I 
t ' 
! ! 
'xxx9MI0O0OO0O01! 
{xx x0O0O0O0101! 
‘oooitlotl1l! 
00011111 
' ! 
! ! 
! 11110141! 
; 11131311121 
{ ' 
! ! 
! ! 


encodings 


! Bits ! 

87654321! 

=------------ L-III----~-,------ 1} 4 [5 7 
DTE originated fo0o00o00g0000! 
pod De somite ted NOY ae concen ee 
! Remote procedure error '00000011! 
| Incompatible destination roo0oolodotl! 
| Local procedure error fo0oo0odaodo0dodl1ldl! 
! Network congestion ‘00000111! 

Where 

(d) When bit 8 is set to 1, the bits 
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represented by Xs are those indicated by 
the remote DTE in the resetting cause 
field of the reset request packet. 


Table 11/AX.25 


Coding of resetting cause field 
in reset indication packet 


OPTIONAL FACILITIES FOR AX.25 LEVEL 3 PROTOCOL 


Terry Fox, WB4JFI 


President, 


AMRAD 


1819 Anderson Rd. 
Falls Church, VA 22043 


Description 


This paper is the third in a series of pap2rs 
that make up a recommendation for the AX.25 
Network Sublayer protocol. 


The purpose of this paper is to describe 
optional user facilities requested of the network 
or called DTE at time of a call request. Included 
in these facilities are standard CCITI recommended 
Facilites, and additional amateur network 
facilities. The amateur facilities are 
suggested by the draft committee, reader 
suggestions or comments are invited. 


Comments may be sent to the author, or sent 
to the AMRAD Newsletter for publication. Follow 
the AMRAD Newsletter for further details. 


7 Procedures and formats for optional user 
~~ facilities ate packet Tevel 


7.1 Procedures for optional user facilities 
associated with virtual Call service 


Sees Ee 


pale Extended packet sequence numbering 


This facility is not presently allowed in 
BX25 


Pad oe Nonstandard default window sizes 


Nonstandard default window sizes is an 
optional user facility agreed. to for a period of 
time. This facility, if subscribed to, provides 
for the selection of default window sizes from the 
list of window sizes supported. Some networks may 
constrain the default window sizes to be the same 
for each direction of data transmission across the 
DTE/DCE interface. In the absence of this 
facility, the default window sizes are 2. 


Values other than the default window sizes 
may be negotiated for a virtual call by means of 
the ogee parameter negotiation facility 
(see 7.2.2). 


fps. Default throughput classes assignment 


This optional facility is not implemented in 
AX E25 


bel4 Packet retransmission 


This optional facility is not implemented in 
BX ooo 


ees Incoming calls barred 


This optional facility is not implemented in 
ROL os 


olieo Outgoing calls barred 


This optional facility is not implemented in 
AX.25. 


Teal One-way logical channel outgoing 


One-way logical channel outgoing is an 
optional user facility agreed: to for a period of 
time. This user facility, if subscribed to, 
restricts the logical channel use to originating 
outgoing virtual calls only. 


A logical channel used for virtual calls 
retains its full duplex capability. 


The rules according to which logical channel 
group numbers and logical channel numbers can be 
assigned to one-way outgoing logical channels for 
virtual calls are given in Annex A 


If all the logical channels for virtual calls 
are one-way outgoing at a DTE/DCE interface, the 
effect is equivalent to the incoming calls barred 
facility (not implemented). 


Vedeed One-way_logical_channel_ incoming 


One-way logical channel incoming is an 
optional user facility agreed to for a period of 
time. This user facility, 1£ it is supported, 
restricts the logical channel use to receivin 
incoming virtual calls only. A logical channe 
used for virtual calls retains its full duplex 
capability. 


The rules according to which logical channel 
group numbers and logical channel numbers can be 
assigned to one-way incoming logical channels for 
virtual calls are given in Annex A. 


If all the logical channels for virtual calls 
are one-way incoming at a DTE/DCE interface, the 
effect is equivalent to the outgoing calls barred 
facility (not implemented). 


ek oo Closed user group 


This optional facility is not supported. 


Tee dog nO Closed user group with outgoing access 


This optional facility is not available in 
BX 22% 
belo tt Closed user group with incoming access 


This optional facility is not available in 
BRE 2S 


Pelt? Incoming calls barred within a closed 


user group 


This optional facility is not available in 
AX.25. 


Pele lS Outgoing calls barred within a closed 
user group 


This optional facility is not available in 
AMZ; 


ie a eee Bilateral closed user group 


This optional facility is not available in 
AX e235 


Tbk Bilateral closed user group. wath 
.—————s “outgoing ac cess =o 


This optional facility is not available in 
AX.25. 


PePerees Reverse charging 


Reverse charging is an optional user facility 
which mav be requested .by a DTE for a given 
virtual call (see 7.4.2.3), and only for the case 
of a virtual call destined for a DTE on a public 
data network. 


Terk d Reverse charging acceptance 


This optional facility is not available in 
AX.25 4 
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7.1.18 RPOA selection 


Recognized private operating agency (RPOA) 
selection is an optional user facility which may 
be requested by a DTE for a given virtual call. 


When this user facility is requested, it 
provides for the user specification by the 
calling/source DTE of a particular RPOA transit 
network through which the call is to be routed 
internationally, when more than one RPOA transit 
network exists at a gateway (see 7.4.2.4). 


iz2 Procedures ‘for: optional user facilities -only 
available with virtual call services 


PA. Nonstandard default packet sizes 


Nonstandard default packet sizes is an 
optional user facility agreed to for a period of 
time. This facility, if subscribed to, provides 
for the selection of default packet sizes from the 
list of packet sizes supported. Some networks ma 
constrain cage Breas sizes to be the same for eac 
direction of ta transmission across the DTE/DCE 
interface. In the absence of this facility, the 
default packet sizes are 128 octets. The term 
"packet sizes" refers to the maximum user data 
field lengths of DCE and DTE data packets. 


Values other than the default packet sizes 
may be negotiated for a virtual call by means of 
the flow control parameter negotiation facility 
(see 7.2.2). 


dowd Flow control parameter negotiation 


Flow parameter negotiation is an optional 
user facility agreed to for a period of time which 
can be use b a DTE on virtual calls. This 
facility, if sub scribed to, permits negotiation on 
a per-call basis of the flow control parameters. 
The flow control parameters considered are the 
packet and window sizes at the DTE/DCE interface 
for each direction of data transmission. 


"Packet sizes" in 7.2.2 refers to the maximum 
user data field lengths of DCE and DTE data 
packets. 


In the absence of the flow control parameter 
negotiation facility, the flow control parameters 
to be used at a particular DTE/DCE interface are 
the default packet sizes (see 7.2.1) and the 
default window sizes (see 7.1.2). 


When the calling DTE has subscribed to the 
flow control parameter negotiation facility, it 
may separately request packet sizes and window 
sizes for each direction of data transmission (see 
7.4.2.5). If a particular window size is not 
explicitly requested in a call request packet, the 
DCE will assume that the default window size was 
requested. If a particular packet size is not 
explicitly requested, the DCE will assume that the 
default packet size was requested. 


When a called DTE has subscribed to the flow 
control parameter negotiation facility, each 
incoming call packet will indicate the packet and 
window sizes from which DTE negotiation can start. 
No relationship needs to exist between the packet 
sizes (P) and window sizes (W) requested in the 
call request packet and those indicated in the 
incoming call packet. The called DTE may request 
window and packet sizes with facilities in the 
call accepted packet. The: only: valid. Paci liey 
requests in the call accepted packet, aS a 
function of the facility indications _in the 
incoming call packet, are given in Table 13/AX.25 
(Table 137 ax. 25 is at the end of this paper). If 
the facility request is not made in the call 
accepted packet, the DTE is assumed to have 
accepted the indicated values (regardless of the 
default values). 


When the calling DTE has subscribed to the 
flow control negotiation facility, every call 
connected packet will indicate the packet and 
window sizes to be used at the DTE/DCE interface 
for the call. The only valid facility indications 
in the call request packet are iven in Table 
14/AX.25 (Table. 14/AX.25 is at the end of this 


paper 


The network may have constraints coquer is 
the flow control parameters used for a call to be 


modified before indicating them to the DTE in the 
incoming call packet or call connected packet; the 
ranges of parameter values available on various 
networks may differ. 


Window and packet sizes need not be the same 
at each end of a virtual call. 


The role of the DCE in negotiating the flow 
control parameters may be network dependant. 


Ti253 Throughput class negotiation 


This parameter is not presently implemented 
in AX.25. 


7.2.4 Fast select 


Fast select is an optional user facility 
which may be requested y a DTE for a given 
Vircual ical l, 


DTES can request the fast select facility on 
a per-call basis by means of an appropriate 
facility request (see 7.4.2.7) in a call request 
packet using any logical channel which has been 
assigned to virtual calls. 


The fast select facility, if requested in the 
call request packet and if it indicates no 
restriction on response, allows this acket to 
contain a call user data field of up to 128 octets 
and authorizes the DCE to transmit to the DTE, 
during the DTE waiting state, a call connected 
packet with a called user data field of up to 128 
octets or a clear indication packet with a clear 
user data field of up to 128 octets. 


The fast select facility, if requested in the 
call request packet and if it indicates 
restriction on response, allows this packet to 
contain a call user data field of up to 128 octets 
and authorizes the DCE to send to the DTE, during 
the DTE waiting state, a clear indication packet 
with a clear user data field of up to 128 octetr 
the DCE would not be authorized to transmit a call 
connected packet. 


The presence of the fast select facility 
indicating no restriction on response in an 
incoming call packet permits the DTE to issue as a 
direct sige tee to this packet a call accepted 
packet with a called user data field of up to 128 
octets or a clear request packet with a clear user 
data field of up to 28 octets. 


The presence of the fast select facility 
indicating restriction on response in an incoming 
call packet permits th.e DTE to issue as a direct 
ees to this packet a clear request packet 
with a clear user data field of up to 128 octets; 
the DTE would not be authorized to send a call 
accepted packet. 


A clear request packet with a clear user data 
field of up to 128 octets at any time other than 
the DCE waiting state (p3) is not allowed. 


The call user data field, the called user 
data field, and the clear user data field will not 
be fragmented for delivery across the DTE/DCE 
interface. 


The significance of the call connected packet 
and the clear indication packet with the cause 
“DTE originated” as a direct response to the call 
request packet with the fast select facility is 
that the call request packet with the data field 
has been received by the called DTE. 


All other procedures of a call in which the 
fast select facility has been requested are the 
same as those of a virtual call. 


If a fast select clear re uest packet with a 
non-zero address length fiel8 or facility length 
field is received, the DCE shall discard the 
received packet. The DCE shall indicate clearing 
by sending to the Bee — clear indication packet 
with a cause "Loc procedure error" an 
diagnostic #74 or #75, as appropriate. The 
distant DTE is also inf’ ormed of the clearing by a 
clear indication packek, with, the cause "Remote 
procedure error" (same diagnostic). 
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(eee Fast select acceptance 

This optional ene | is not implemented in 
AX.25. All users should allow fast select. 
7.2.6 Charging information 

This optional facility is not implemented in 
AX. 25. 
7.2.7 D bit modification 

This optional facility is not implemented in 
AX. 25. 
7.2.8 Hunt group 


is an optional user facility 
agreed to for a period of time. This user 
facility, if subscribed to, distributes incoming 
calls having an address associated with the hunt 
group across a designated grouping of DTE/DCE 
interfaces. 


Hunt group 


Selection is performed for an incomin 
virtual call if there is at least one idle logica 
channel available for virtual calls on any DTE/DCE 
interface in a group. Once a virtual call is 
assigned to a DTE/DCE interface, it is treated as 
a regular call. 


When virtual calls are placed to a hunt group 
address in the case specific addresses have also 
been assigned to the individual DTE/DCE 
interfaces, the call connected or clear indication 
packet sent to the calling DTE will optionally 
contain the called address of the selected DTE/DCE 
interface and the called line address modified 
notification facility indicating the reason why 
the called address is different from the one 
originally requested. 


Virtual calls may be originated on DTE/DCE 
interfaces belonging to the hunt group; these are 
handled in the normal manner. In particular, the 
calling DTE address transferred to the remote DTE 
in the incoming call packet is the hunt group 
unless the DTE/DCE interface has a specific 
address assigned. Some networks may place a limit 
on the number of DTE/DCE interfaces in the hunt 
group, and/or constrain the size of the geographic 
region that can be served by a single hunt group. 


7.2.9 


Call redirection “Ls: an optional. facility 
agreed to for a period of time. This user 
facility, if subscribed to by a DTE, redirects 
incoming calls destined to this DTE, when: 


1) 
2) 


Some networks may provide call redirection 
in the case of 1) above. 


Call redirection 


the called DTE is out-of-order, or 


the called DTE is busy. 


only 


In addition, some networks may offer: 


3) systematic call redirection with prior 
request of the called DTE. 


The basic service is limited to one call 
redirection. In addition, some networks may offer 
either one of the following (mutually exclusive) 
capabilities: 


A) A list of alternate DTEs (cl, c2,¢3, ...etc) 
is stored by the network of the originally 
called DTE OME B). consecutive attempts of 
call redirection are tried to each of these 
addresses, in the order of the list, up to 
the completion of the call; 


Call redirections may be logically chained; 
if DTE C has subscribed to call redirection 
to DIE D, the call may be redirected to D 
even if it was originally addressed to B. 


B) 


In any case, networks will ensure that loops 
are avoided and that connection establishment 
phase has a limited duration. 


If a call is cleared by the network as a 
consequence of the actions taken to this effect, 


the clearing cause is the one generated at the 
last DTE/DCE interface. 


When the virtual call is redirected, the call 
connected or clear indication packets sent to the 
calling DTE will contain the called address of the 
alternate DTE and the calling line address 
modified notification facility, indicating the 
reason why the called address is different from 
the one originally requested. 


When the virtual call is redirected, some 
networks may indicate to the alternate DTE the 
reason for redirection and the address of the 
originally called DTE, using the call redirection 
notification facility in the incoming call packet. 


The order of call set-up processing at the 
Orie inelty called DCE as well as the alternate DCE 
will be according to the sequence of call progress 
signals in Table 1/AX.96. For those networks that 
provide systematic call redirection with the prior 
re uest of the called DTE, the systematic call 
re8irection request will have the highest priority 
in the call set-up processing sequence at the 
originally called DCE. 

line 


7.2.10 Called ine 
“notification 


modified 


ee Em aD reg ee cee coe og 


Called line address modified notification is 
a user facility, used by the DCE in the call 
connected or clear indication packets to inform 
the calling DTE as to why the called address, if 
present, in these packets is different from that 
specified in the call request packets. 


The following reasons can be indicated with 


the use of called line address modified 

notification facility: 

1) Call distribution within a Hunt Group. 

2) Call redirection due to originally called DTE 
out of order. 

3) Call redirection due to originally called DTE 
busy. 

4) Call redirection due to prior request from 
the originally called DTE for systematic call 
redirection. 

e224 Call redirection notification 
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Call redirection notification is a user 


facility, used by the DCE in the Encoens call 
packet to inform the alternate DTE as to w the 
call is redirected, and the address of the 


originally called DTE. 


The following reasons can be indicated with 
the call redirection notification facility: 


1) Call redirection due to originally called DTE 
out of order. 

2) Call redirection due to originally called DTE 
busy. 

3) Call redirection due to prior request from 
the originally called DTE for systematic call 
redirection. 

7.2.12 Amateur networking facilities 


The following describes optional amateur 
radio networking facilities. These facilities are 
interim recommendations, subject to corrections. 


One of the two amateur routing facilities 
must be provided when connections are requested 
outside the local network. 


7.2.12.1 Amateur network. facility marker 


The amateur related networking optional 
facilities must follow the CCITT optional 
facilities, and shall be separated from the CCITT 
facilities by a special two octet amateur marker. 


7.2.12.2 Amateur explicit routing facility 


The amateur explicit routing facility is an 
optional user facility that allows the calling DTE 
to specify the route of a connection. 


When this facility is selected, the calling 
DTE must provide a list of addresses which will be 
used by the network to route the call to the 
called DTE. 


7.2.12.3 Amateur implicit routing facility 


The amateur implicit routing facility is an 
optional user facility that allows the network to 
route the call based on geographical information 
supplied by the calling DTE. 


When this facility is selected, the calling 
DTE must provide the geographical location of the 
called DTE. 


(eae Additional optional facilities 


In addition to the above facilities, others 
may be added as necessary. Subject for further 
study are certain X.75 utilities, such as call 
control. 


7.3 Procedures for coprional user facilities only 
available with Datagram service 


These facilities are not implemented in AX.25 


7.4 Formats for optional user facilities 
rele General 


The facility field is present only when a DTE 
is using an optional user facility requiring some 
indication in the call request, incoming call, 


call accepted, call connected, clear request, or 
clear indication. 

The facility field contains one of more 
facility elements. The first octet of each 
facility element contains a facility code to 
indicate the facility or facilities requested. 

The facility codes are divided into four 
classes, by making use of bits 8 and 7 of the 


facility code field, in order to specify facility 
parameters consisting of 1, 2, 3, or a variable 
number of octets. The general class coding of the 
facility code field is shown in Table 15/AX.25 
(Table 15/AX.25 is at the end of this paper). 


For class D the octet following the facility 


code indicates the length, in octets, of the 
facility parameter field. The facility parameter 
field length is binary coded, with bit 1 being the 


low order bit. 


The formats for the four classes are shown in 
Table 16/AX.25. 


The facility code field is binary coded and 
without extension, provides for a maximum of 64 
facility codes for classes A, B, and C, and 63 
facility codes: for -class D giving a total of 255 


facility codes. 

Facility code 11111111 is reserved for 
extension of the facility code. The octet 
following this octet indicates an extended 
facility code having the format A, B, C, or D as 
define above. Repetition of facility code 
11111111 is permitted and thus) additional 


extensions may result. 


The coding of the facility parameter field is 
dependent on the facility being requested. 


A facility code may be assigned to identify a 
number of specific facilities, each having a bit 


in, the, parameter tiela indicating “facility 
requested/facility not re quested. Re Tenis 
situation, the parameter fiel is binary encoded 


with each bit position relating to a specific 
facility. A 0 indicates that the facility related 
to the particular bit is not requested anda l 
indicates that the facility related to the 
particular bit is requested. Parameter bits not 
assigned to a specific facility are set to 0. If 
none of the facilities represented by the facility 
code are requested for a virtual call, the 
facility code and its associated parameter field 
need not be present. 


A facility marker, consisting of a single 
octet pair, is used to separate requests for AX.25 
facilities, as defined in this section, from 
requests for non-AX.25 facilities that also may be 
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offered by a network. The first octet is a 
facility code and is set to zero, and the second 
octet is the facility parameter field. 


The coding of the parameter field will be 
either all zeros or all ones depending on whether 
the facility requests following the marker refer 
EO facilities offered calling/source or 
called/destination network, respectively. For 
intranetwork virtual calls, the parameter field 
should be all zeros. 


Requests for non-AX.25 facilities offered by 
the calling/source and called/destination networks 
may Simultaneously present within the facilit 
field and in such cases two facility markers wilt 
be required with parameter fields coded as 
described above. 


Within the facility field, requests for AX.25 
facilities will precede-all requests for non-AxX.25 
facilities and facility markers need only be 
present when requests for non-AX.25 facilities are 
present. 


Class A Class B 
bits 8 7 65 43 2 1 bits 8765432 1 
0 0 : 0Oooxxxxx x! 0 O! 01X X XK XK X XK 
C acl ieclateieateteteetetetatadad C [lower enn ser nencnna! 
T ! Facility ! T 1! Facility ' 
E 1 ! Parameter Field ! E Jaen arate 
db sd ad T 2 ! Parameter Field ! 

Class C Class D 

bits 8 7 6 5 4 3 2 1 bits 8 7 6 5 4 32 I 
oo! 10xXKxXKxXxXK xX xX! OQ: web Jd aes See 
C { Pe ed a> hoe | C leew ewenwes a a { 
T 4.) Facility ! T 1! Facility ! 
E f--- ---!] E fone ~--! 
T 2! Parameter fet 2) Parameter ! 
31 Field “ Vo fess Pyeld <1 
eee werent anw ee wena an a A ! 
R a a aa a nee ae ws eo ee 
Table 16/AX.25 
Facility Class Coding 
PAZ Coding of facility field for particular 
acilities -—- 
Tig be Dg Coding of RPOA selection facility 


7.4.2.4.1 Facility code field 
The coding of the facility code field for 
RPOA selection is: 


bit: 8 
code: @) 


fede 2 ete. Pacwiity parameter ftretd 


The parameter field contains the data network 
identification code for the requested RPOA transit 
network, and is in a form of four decimal digits. 


Fach digit is coded in a semi-octet (nibble) 
in binary coded decimal wité bit 5 of the first 
octet being the low order bit of the first digit, 
bit L-O£ the first octet. being the low order-b1t 
of the second digit, bit 5 of the second octet 
being the low order bit of the third digit, and 
bit 1--6f the- second octet. being the low order .bit 
of. the Fourtir digit; 


ete? ey Coding of flow control parameter 
facility negotiation — 


The coding of the facility code field and the 
format of the facility parameter field for packet 
Sizes are the same in call request, incoming call, 
call accepted, and call connected packets. 


7.4.2.5.1.1 Facility. code field 


_. The coding of &he facility code for packet 
sizes is: 


bit: 87654321 
Gs Kaira 6 es 6) aes 9 es a 6 
7.4.2,5.1.2 Facility parameter field 


The packet size for the direction. of 
transmission from the called DTE is indicated in 
bits 4, 3, 2, and 1 of the first q@outtet. The 
packet size for the direction of transmission from 
the calling DTE is indicated in_bits 4, 3, 2, and 
1 of the second octet. Bits 5, 6, 7, and 8 of 
each octet must be zero. 


The four bits indicating each packet size are 
binary coded and express the logarithm base 2 of 
the number of octets of the maximum packet size. 


Networks may offer values from 4 to 12, 
corres con ne ve to packet sizes of 16, 32, 64, 128, 
25%, 512. TAs 2048, or 4096, or a Subset of 
these calaes’ All networks’ should provide a 
packet size of 128. 


7.4.2.5.2 Coding for window sizes 


The coding of the facility code field and the 
format of the facility parameter field for window 
sizes are the same in call request, incoming call, 
call accepted, and call connected packets. 


J.4,2.5.2,1, Facility code field 


The coding of the facility code field for 
window sizes is: 


bit: 87654321 
es i 0 ae @ res CO aes Baw 


TeAgZoe2ee Facility parameter tield 


The window size for the direction of 
transmission from the called DTE is indicated in 
bits 7 to 1 of the first octet. The window size 
for the direction of transmission from the callin 
DTE is indicated in bits 7 to 1 of the secon 
octet. Bit 8 of each octet must be zero. 


The bits indicating each window size are 
binary coded and express the size of the window. 
A value of zero is not allowed. 


Window sizes of 8 to 128 are not allowed in 
AX.25. All networks will provide a window g1ze of 


pie eee) Coding of fast select facility 


The coding of the facility code and parameter 
fields for fast select is the same in call request 
and incoming call packets. 


iefe2e tl Facility code. field 
The -coding: of “the: facility code: field for 
fast select is: 
bit: 87654321 
code: OO 30:20 0G Oa 
LAas2 led Facility parameter field 
The coding of the facility parameter field 
is: 


Bit 8=0 and bit 7#0 or 1 for fast select not 
requested. 


Bit 8=1 and bit 7#0 for fast select requested 
with no restriction on response. 


Bit 8=1 and bit 7=1 for fast select requested 
with restriction on response. 


Bits 6, 5, 4, 3, and 2 may be used for other 
facilities. If not they are set to zero. 
Use: of bit l us described in section. 7i4.2.3: 


7.4.2.11 Vodrng or caliea line address modified 


not ification 


Ly meee 


7,.4.2.11.2 


Facility code field 


coding of the facility code field for 
called Vine address modified notification is: 


bit: 87654321 
code : 00001000 


Facility parameter field 


The coding of the poet tty parameter field 
for called line address modified notification is: 


bits: 87654321 
000003111 Call distribution within 
a Hunt Group. 
00000001 Call redirection due to 
ot aaa called DTE 
usy. 
0.00 0-20 0 t- Call redirection due ‘to 
originally called DTE 
out of order. 
Call redirection. due. to 
prior request from 
originally called DTE 
for systematic ‘call 
redirection. 


Of io Oe Oe de a a 


7.4.2.12 Coding of call redirection notification 


Facility code field 


The, coding of the facility code field for 
call redirection notification is: 


bit: Of 625 eb Se ob 
code: 11000011 


Facility parameter field 


The: octet following the facility code freld 
indicates: the: length in octets of the facility 
parameter field and has the value n+2 where n is 
the number of octets necessary to hold the 
originally called DTE address. 


The second octet indicates the reason for the 
aoe redirection and has one of the following 
values: 


DLESs Oo db br os 2d 
OOO) 20 0 OO. oT pee called DTE 


bus 

OO Oo 1 Oy 1 Orizinally called DTE 
out of order 

OOO Od Lak “Systemarteca lt. 
redirection 


The third octet indicates, in bits 4, 3,2, 
and 1, the number of nibbles in the originally 
called DTE address. This address Length indicator 
is binary coded, with bit 1 being the low order 
bit. “Bits 8, 1s 6, “and: S-or “this: oclet. ‘are ‘set. to 
zero. 


The following occ (up to ene contain 
the oritinal’y called DTE address coded 
identically to the called DTE address field in the 
call request packet (see 6.2.1.3). 


i re orl Coding of amateur network facilities 


fee en GG ee | Codingor tne: amateurnetwork 
facili tess marker 


The amateur network facilities marker field 
consists of two octets and is coded as folows: 


bits: SH a comes aan ato maya 


octetl: 00000000 
octet2: 111111190 


7.4.13.2 Coding of amateur network explicit 
routing facility 


Taal sede, Bac iiaity..code: Tie la 


The coding of the facility code field for the 
amateur network explicit routing is: 


Bis: Mme a Se me Go me a 
code: 30:30: 0520 0).0 
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7.4.13.2.2 Facility parameter field 


The coding of the facility parameter field in 
the amateur network explicit routing facility is 
as follows: 


The first octet is called the explicit length 
octet., and contains the total length of the 
facility, including the code field and the length 
octet. This length octet is binary coded, and 
cannot be zero. 


The octets following the length octet contain 
the packet switch identifier(s) that indicate 
which switches the call should progress through. 


The packet switch identifier consists of the 
six unshifted ASCII characters of the amateur 
callsign EPCS case alpha and numeric characters 
only) of the packet switch, followed by an 
additional octet that contains a five-bit station 


subaddress. The station subaddress information is 
contained in bits 5, 4, 3, 2, and 1 of the seventh 
octet. Bits 8, 7, and 6 of the subaddress octet 
are reserved, and set to zero. If the callsign 
contains less than six ASCII characters, the 
callsign will be padded with trailing ASCII spaces 
between the last callsign character and the 
subaddress. 

Up to 38 packet switch identifiers are 
allowed, the first identifier will identify the 
first packet switch in the chain. Additional 


following the first in order of 
ing DTE to the called 


switch identifiers 
call progress from the cal 
DTE. 


Other methods of explicit routing are a 


subject. for further study. 


7.4.13.3 Coding of amateur network implicit 
routing-facility 


7.4.13.3.1 Facility code field 


The coding of the facility code field for the 
amateur network implicit routing facility is: 
continued next  column.... 


7.4.13.3.2 Facility parameter field 


The coding of the facility parameter field 
for the amateur network implicit routing facility 
consists of three octets. 


arameter is a subject for 
further study. The following information is one 
suggested method of coding this information, based 
on the geographical location of the called DTE. 


The coding of this 


The first octet contains the Low itude i 
degrees of the called station, from to 180 
based on Greenwich, England. This octet is binary 
encoded, with bit 8 being the most-significant 
bit, and bit 1. the Lleast=significant bit. 

The second octet contains the Latitude of the 
called station in degrees. Bit 8 indicates 


whether the called DTE is north or south of the 
equator (zero equals north, one equals south). 
Bits 7 to 1 contain the Latitude in degrees, from 
0 to 89. This data is binary coded, with bit 7 
being the MSB, and bit l is the LSB. 


The third octet contains an east/west marker 


Dat and grid information within the 
Latitude/Longitude specified. 
Bait. <8 pot the. “third octet... contains the 


east/west marker for the Longitude information. 
If bit 8 is a zero, the Longitude information is 
west of Greenwich, while a one indicates the 
information is east of Greenwich. 


The remaining seven bits contain information 
on where within the square (resulting from the 
Latitude/Longitude information above) the station 
is located. Actual coding of this field is a 
subject for further study. 


Other methods of encoding the amateur network 
implicit routing facility are subject to further 
study. One method might be to use National 
Traffic System abbreviations. Comments or 
suggestions are welcome. 


Wind eat ee. =>2 ! W(indicated) =>W(requested) =>2 ! 
! W(indicated) = 1 | W(requested) = lor 2000 
foe ee eee een nnn fr , 
sp tnd teat eds =>128 ! P(indicated) =>P(requested)=>128! 
'P(indicated) < 128 !128 =>P(requested) =>P(indicated)! 


Table 13/AX.25 


Valid facilit 


requests in call accepted packets 


in response to facility indications in incoming call packets 


| Facility request ! Valid facility indication : 
[re a Ee ae ee ee ee we ee ae | 
! W eeaneat ec! =>2 ! Nie Bestee =>W(indicated) =>2 ! 
! W(requested) = 1 W(indicated) = 1 or 2 ! 
HOD clot least eg A Rae (ea incr pete OR, 


1P(requested} 
!P( requested 


=>128 ! P(requested) 
< 128 !128 =>P(indicated) 


=>P(indicated)=>128! 
=>P(requested)! 


Table 14/AX.25 
Valid facility indications in call connected packets 
in response to facility requests in call requests packets 


! parameter ' 
! for sing le octet parameter ! 
! for double octet parameter |! 
! for triple octet parameter ! 
! 


variable lenght param. ! 


| Class !| 87654321 

[ ene ewww ww ween 

Class A 10 0) xe xe xX 

' Class B ! 01X XX X X X 

' Class C !10X XX X X X 

i! Class Di 1ixXXXxXxX 
Where X can 


be either a zero or one. 


Table 15/AX.25 
Facility Class Coding 
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ANNEX A THROUGH F FOR AX.25 LEVEL 3 PROTOCOL 


Terry Fox, WB4JFI 


President, 


AMRAD 


1819 Anderson Rd. 
Falls Church, VA 22043 


Description 


This is the fourth of four papers that make 
up a recommendation for the AX.25 Network Sublayer 
protocol. 


This paper contains the annexes for the 
previous three papers. These annexes are based on 
the CCITT X.25 document, modified as necessary to 
operate in the amateur enviroment. 


This paper is a draft, and subject to change. 
Anyone wishing to offer comments or suggestions 
should write the author at the above address, or 
write to the AMRAD Newsletter for publication. 


ANNEX A 


Range of logical channels used for virtual calls 


In the case of a single logical channel DTE, 
logical channel number 1 will be used. 


For each multiple logical channel DTE/DCE 
interface, a eu a of logical channels will be 
agreed upon wit the Network Adminidtration 
according to Figure A-1/AX.25. 


One-Way ! 
Incoming ! 
Channels ! 
{Vv 
! 1 
ase 
Two-Way Channels 'TA 
!uL 
LAL 
{Ls 
One-way ' 
Outgoing l 
Channels i 
HOC .ean aS Soe Sees Sen 
4095 ! 
Where: 
LCN *= Logical channel number 
LIC = Lowest Incoming call number 
HIC = Highest Incoming call number 
LTC = Lowest Two-way call number 
HTC = Highest Two-way call number 
LOC = Lowest Outgoing call number 


Highest Outgoing call number 


Figure A-1/AX.25 


LIC to HIC: range of logical channels assigned to 
seat incoming channels for virtual 
calls. 


The present recommendation is to 
assign 1 as the LIC, and 3 as the HIC. 


LTC to HTC: range of logical channels which are 
assigned to two-way logical channels 
for virtual calls. 


The present recommendation is to 
aot 4 as the LTC, and 4079 as the 
ALC 


LOC to HOC: range of logical channels assigned for 
use as one-way outgoing channels for 
virtual calls. 


The present recommendation is to 
assign 4080 as the LOC, and 4095 as 
the HOC. 


The reference to the number of logical 
channels is made according to a set of 
contiguous numoers from 0 (lowest) to 
4095 (highest) using 12 bits made up 
of the logical channel group number 
(LCGN) (see 6.1.2) and the 8 bits of 
the logical channel number (see 
6.1.3). The numbering is binary coded 
using bit positions to 1 of octets 1 
followed by bit positions 8 through 1 
of octet followed by bit positions 8 
through 1 sof octet 2 with. bit: 1 o£ 
octet being the low order bit. 


Note 1: 


Note 2: All logical channel boundaries are 


agreed to for a period of time. 
Note 3: DCE search algorithm for a logical 
channel for a new incoming call will 
be to use the lowest logical channel 
in the ready state in the range of LIC 
to HIC or LTC to HTC, depending on 
whether the call is one-way incoming 
or two-way, respectively. 
Note 4: In order to minimize the risk of call 
collision, the DTE search algorithm is 
suggested to start with the highest 
numbered logical channel in the ready 


state, 
ANNEX B 
B.1 Symbol definition of the state diagram 
PEt sone 
! 
! V 


ewiesiuse ! eeeowoas 
! State \ 
! Number 


! oS Responsibility 
! (DTE for the 
pass ae am aa transition 


Transition 
! (Packet <-e"- Packet 
V type) transferred 


Note 1. Each state is represented noe ellipse 
wherein the state name and number are 
indicated. 


Note 2. Each state transition is represented by 
an arrow. The responsibility for the 
transition (DTE or DCE) and the packet 
that has been transferred as indicated 
beside the arrow. 


B.2 Order definition of the state diagram 


For the sake of clarity, the normal procedure 
at the interface is described in a number of small 
state diagrams. In order to describe the normal 
procedure fully, it 1s necessary to allocate a 
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Pee co the different figures and to relate a 
igher order diagram with a lower one. This has 
been done by one of the following means: 


The figures have been arranged in order 


of priority with Figure B-1/AX.25 (restart) having 
the highest priority and subsequent figures having 


DTE 


Restart request 


or Restart 
indication 


Restart request 


acket level ready 


lower priority. Priority means that when a packet 
belonging to a higher order diagram is 
transferred, that diagram is applicable and the 
lower one is not. 


The relation with a state in a lower order 
diagram is given by including that state inside an 
ellipse in the higher order diagram. 


DCE 


Restart 
Indication 


restart 
indicat- 
ion 


> 
| DCE 


Restart indication 
(see Note 1) 


Note 1. This transition may take place sfter time-out T10. 


Figure B-1/AX.25 


Diagram of states for the transfer of restart packets 


DTE 
Call 
Request 
Incoming 
call 


Call 
connected 


request 


pd 
Call *& 
'collis- 
CE 
Y 


'connected Carl 


transfer 


EX 


ady;} DCE 


\ / Incoming 
call 


Call 


accepted 


Figure B-2AfAxX.25 
Call set-up phase 


any state 


DTE except DCE 
p6 or p7 
Clear Clear 
7 request sustcation! 


DCE DTE 


Clear 
| request 
request /&* 
Call 
connected 
(see Note > 
or DCE Clear DTE Clear 
Incoming confirmation confirmation Call 
Call or Clear indication or Clear request request 
(see see Note 
Note 5)) 4) 


Note 1. This transition is possible only if the previous state 
was DTE waiting (p2). 


Note 2. This transition is only possible if the previous state 
was DCE waiting (p3). 


Note 3. This transition may take place after time-out T13. 


Note 4. This transition is possible only. if the previous state 
was Ready (pl) or DCE waiting (p3). 


Note 5. This transition is possible only. if the previous state 
was Ready (pl) or DTE waiting (p2). 


Pigure B-2B/AX.25 
call clearing phase 


Diagrams of states for the transfer of call,set-up and call 
clearing packets within the packet level ready (pl) state. 


DTE 
Reset 


Reset _Kes ; 
indication 


request 


DCE 


DTE 


Reset Reset 
indication request 


request 


or DCE or DTE : 

Reset Reset Reset Reset 
request confirmation confirmation indication 
(see Note) 


Note: this transition may take place after time-out T12 
Figure B-3/AX.25 


Diagram of states for the transfer of reset packets 
within the data transfer (p4) state 
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ANNEX C 


Actions taken by the DCE on receipt of packets 
in a given state of the packet level DTE/DCE 
as perceived by the DCE 


INTRODUCTION 


This Annex specifies the actions taken by the 
DCE on receipt ofpackets in a given state of the 
packet level DTE/DCE interface as perceived by the 
DTE. 


It is presented as a succession of chained 
tables. 


The following rules are valid for all these 
tables: 
1) There may be more than one error associated 
with a packet. The network will stop normal 
processing of a packet when an error is 
encountered. Thus, only one diagnostic code 
is associated with an error indication by 
the DCE. The order of packet decoding and 
checking on networks is NOT standardized. 
2) The detection of the non-octet alignment 
shall be made at the frame level 
3) In each table, tha actions taken by the DCE 
are indicated in the following way: 


A) Discard: The DCE discards the received 
packet and takes no subsequent action as a 


direct result of receiving that packet, the 


DCE remains in the same state. 


B) DIAG # x: The DCE discards the received 

packet and, for networks which implement the 

diagnostic packet, transmits to the DTE a 

diagnostic packet containing the diagnostic 
Xs 


C) NORMAL or ERROR: The corresponding 
action is specified behind each table. 


4) Annex E gives a list of the diagnostic codes 
which may be used. 
Table C-1/AX.25 
Special Cases 

a Soe Se ee a a ee, a, eee 
| Packet from the DTE !Any State! 
[er ee eg ee de SSS SS SS SS eee 
! Any packet with packet length | DTAG ! 
| shorter than two octets | #38 
! Any packet with an incorrect | DIAG 
! general format identifier (GFI) !_ #40 

{wwe ummoaceeraanrererwrnanecese core ne wee 1 ole oy te | 
! Any poee with an unassigned | DIAG ! 
ogical channel joe 136.0] 
! Any packet with correct GFI and ! See I 
| assigned logical channle or with |. Table ! 
| bits 1 to 4 of octet 1 and bits !C-2/AX. 25! 


fd te 2 of octet 2 equal to zero ! 


State of the interface! ! ! ! 
erceived by ! Packet ! DTE ! DCE ! 

e DTE ! Level ! Restart ! Restart ! 

! Ready ! Request !Indication! 

rom ! ! ! ! 

DTE with aesigne ! rl ! r2 ! r3 ! 
logical channel ! ! ! 

I Restart Request ! Normal ! Discard : Normal ! 
| J On) 1, ! (rl) ! 
res maaan ee ween eweewseeen | re ee ee ! wewanmnmwwawe | we ewww eww ew ow oe q 
H DTE Restart 'Error #17 1Error #18! Normal ! 
Confirmation ; (r3) ! (r3) ! (rl) 
1 a om eannmneeenee = ene eae fa @& Se Se eet emewnmeeweee Tl eweeee@e@eaeene i wee weee ee a= 3 
! Data, interrupt, call =!see Table!Error #18! Discard ! 


! set-up and clearing, 
{ flow control or reset | 


! Restart request or DTE 
| restart confirmation 

! with bits 1 to 4 of | 
! octet 1 or bits 1 to 8 ! 
; octet 2 unequal to zero! 
! Packets having a P: 

| type identifier which 
| is shorter than 1 octet! 
| or is not supported ! 
! by the DTE I 


! Packet other than 
! restart request and DTE! 
| restart confirmation ! 
! with bits 1 to 4 of ! 
| -octet 1 and bits 1 to 8! 
|! of octet 2 equal to 0 |! 


1C-3/AX.25! 


J----a---- 


(r3) .! ! 


'ebe Table!Error #41! Discard 
1C-3/AX. 


! 

25! r3) ~«! } 
| I 
I 


Ackerlsse Table lerror #38! Discard ' 
1C-3/AX. peo RETO ee 


i 
Yi TAG 


TABLE C-2/AX.25 


Action taken by the DCE on recei 
acket 


in a given state of 


the 


interface as perceived 
procedure for assigned 
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y the DCE: 
° 


re of TE) DCE 
evel DTE/DCE 
restart 
gical channels. 


Where: 
Error (r3): 


The DCE discards Ee received packet, 

indicates a fF restarting 
by sending to rhe DTE a restart 
indication packet with the cause 
"hOCal procedure error" and. the 
diagnostic # x, and enters state r3. 

If connected through a virtual call, 

the distant DTE is also informed of 
the Pee by a clear indication 
packet, ek the cause "Remote 


NORMAL (r1): 


Provided none of the following 
error conditions has occured, the 
action taken by the DCE follows the 
procedure as defined by in section 3, 
ane the DTE/DCE interface enters state 


a) If a restart request packet or DTE 
restart confirmation packet received 
in state r3 exceeds the maximum 
permitted length or is too short, the 
DCE will invoke the ERROR #39 or #38 


! octet or is not | 


procedure ee (Same diagnostic). procedure, respectively. 
If a restart indication is issued as a 
result of an error condition in state b) If a restart request acket 
r2, the DCE should eventually (after a received in state rl exceeds the 
time which does not exceed 120 maximum permitted length, 1S: too 
seconds) consider Che . DIE/DCE short, or the restarting cause field 
interface to be in the packet level is not "DTE originated", the DCE shall 
ready state (rl). invoke the DIAG #32, 838, or #81. 

! State of the ! ! ! ! ! ! ! ! 

! interface as ! ! ! ! ! ! ! ! 

! perceived by ! Ready ! DTE ! DCE ! Data ! Call ! DTE ! DTE ! 

! the DTE ! ! Waiting ! Waiting ! Transfer iCollision| Clear ! Clear ! 

!Packet from the ! ! ! ! ! ! request !indication! 

!IDTE with logical ! pl ! p2 ! p3 ! p4 ! p5 ! p6 ! p7 ! 

assigned to the\! ! ! ! ! ! ! ! 

! virtual call ____\ Phoeeueube Eiidiesede bikes eee ere eS ee ee eee 

| Call ! Normal ! Error ! Normal ! Error ! Error ! Error ! Discard ! 

| Request | ! #27 | ! #23 ! #24 ! #25 ! | 

: (p2) (p7) ! (p5) (p7) } (p7) (p7) : 

! Call ! Error ! Error ! Normal ! Error ! Error ! Error ! Discard ! 

! Accepted ! #20 ! #21 ! ! = #23 ! #24 ! #25 ! ! 

! (p7) ! (p7) ! (p4) ! (p7) } (p7) (p7) 

[ Clear Normal ! Normal ! Normal ! Normal ! Normal ! Discard ! Normal ! 

Request (p6) (p6) p6) (p6) , ‘p6) (p6) ! 

| DTE | Error ! Error ! Error ! Error ! Error ! Error ! Normal ! 

| Clear | 20 ! 21 ! #22 ! #23 ! #24 ! #25 ! ! 

Confirmation , (p7) (p7) : (p7) : (p7) : (p7) (p7) ! (pl) H 

! Data, Interrupt, ! Error ! Error ! Error !see Table! Error ! Error ! Discard ! 

| Reset or Flow ! #20 ! #21 | #22 1C-4/AX.25! #24 1! #25 ! ! 

Control (p7) ! (p7) ! (p7) (p7) ! (p7) ! ; 

' Restart request, ! Error ! Error ! Error !see Table! Error ! Error ! Discard ! 

| or DTE restart ! #41 #41 ! #41 1C-4/AX.25! #41 ! #41 ! ! 

! confirmation with ! (p7) I (p7) ! (p7) ! ! (p7) ! (p7) ! | 

bits 4 to 1 of ! | | | | | | | 

! octet 1 or bits 1! | ! | ! ! | | 

Lvi®.-B.. Of sOChet 2 ! | ! | ! | | I 

L unequal to zero t | { | | ! | 1 

| eee ee eee ee eee [eee nn enn !--------- [enn menonn [--------- Jewennnn-- fereennen= Pemencnene= ! 

! Packets having a ! Error ! Error ! Error !see Table! Error ! Error ! Discard ! 

! packet type i ent-! #38 8! #38 F38 = =!C-4/AX.25! = #38 #38 = ' 

| ifier which is ! #33. ! #33 =O! #33. =! #33. ! #33 ! 1 

! shorter than one ! (p7) ! (p7) !  (p7) (p7) (p7) | 

| | ! 


Where: 
Error (p7): 


! ebppertee by I 


DCE 


TABLE C-3/AX.25 


Action taken hd 
state of the packe 
the DCE: 


call set-up and clearing on 


logi 


assigned to the virtual call. 


The DCE discards the received packet, 
indicates a clearing by Erovsmati sng 
to the DTE aeeclear 

indication packet, with the "Local 
procedure error" and the diagnostic # 
x, and enters state p7. If connected 
through a virtual call, the distane 
DIE is also informed of the clearing 
by a clear indication packet, with the 
cause "Remote procedure error" (same 
diagnostic). 


It is required that in the absence of 
an appropriate DTE response to a clear 
indication packet issued as a result 
of an error condition in state p6, the 
DCE should eventually consider (after 


N 
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ormal (pl): 


the DCE on repeipt of packets in a given 
t level DTE/DCE anECE Eat as 


perce tyes by 


cal channel 


a time which does not exceed 120 
seconds) the DTE/DCE interface to be 
in the ready state (pl). 


Provided none of the following 
error conditions has occured, the 
action taken by the DCE follows the 
procedures as defined in section 4 and 
the DTE/DCE interface enters state pl. 
In all. the: -cases specified hereunder, 
the DCE will transmit to the DCE a 
clear indication with the appropriate 
a and diagnostic, and enter state 

;. 1f connected through a virtual 
Pl the distant DTE is also informed 
of the clearing by a clear indication 
packet with the cause "Remote 
procedure error" (same diagnostic). 


a) Call request packet 
Error Condition Cause Specific 
diagnostics 
. (see Note 3 
1. Not applicable of ANNEX E) 
2. not applicable 
3. Address contains Local procedure # 67,68 
a non-BCD digit error 
4, Prefix digit not Local procedure # 67,68 
supported error 
5. National address Local procedure # 67,68 
smaller than national Error 
address format permits 
6. National address Local procedure # 67,68 
larger than national error 
address format permits 
Error Condition Cause Specific 
diagnostics 


LO: 


sale 


LZ. 


ie 


14. 


ioe 


L6 . 


Ls 


LS 


the network, 


(see Note 3 
of ANNEX E) 


DNIC less than four 
digits 


Local procedure 
error 


bits 7 or 8 of octet Local procedure 
which indicates the error 
facility field length 

not set to zero 


Local procedure 
error 


no combination of 
facilities could 
equal facility length 


Facility length Local procedure 


larger than remainder error 

of packets 

Facility values tnvalrvd) facility 
conflicts (ex. a request 
particular combination 

not supported). 


Invalid facility 
request 


Facility code not 
allowed. 


Invalid facility 
request 


Facility value 
not allowed 


Packet too short Local procedure 


error 
Address length Local procedure 
larger than remainder error 
of packet 
Call user data Local procedure 
larger than 16, or error 


i278 in ‘case of fast 
select facility 


procedure 
error 


Class coding of the Local 
facility corresponding 

to a length of 

parameter larger than 
remainder of packet 


Local procedure 
error 


Facility code 
repeated 


# 67,68 


# 69 


# 69 


# 38 


# 66 


# 65 


# 66 


# 38 


# 38 


# 39 


# 69 


# 73 


If a virtual call cannot be established by 


the DCE should use a call progress 


Signal and diagnostic code among those listed 
hereunder: 


Error Condition 


19 
20. 
obs 
ae 


Cause 


Speciric 


diagnostics 
(see Note 3 
of ANNEX E) 


Unknown station Not obtainable 


Not applicable 
Not applicable 
Reverse charging 


acceptance not 
subscribed 


Reverse charging 
rejected 


# 67 


# 0 


Zo Fast Select Fast select # 0 
rejected acceptance not 
sub scribed 
24. Called DTE out Out of order # 0 
of order # greater 
ehen 128 
25. No logical channel Number busy # 71 
available 
26... Call collision Number busy # 71,72 
27. RPOA out of order RPOA out of order # 0 
28. Temporary network Network congestion # 0 
congestion of fault 
condition within the 
network 
29. The remote DTE/DCE Incompatible # 0 
interface or the destination 
transit network does 
not support a function 
or a facility requested 
30. Procedure error at Remote procedure see b 
the remote DTE/DCE error and c 
interface and ANNEX D 
b) Call accepted packet 
Error condition Cause Specific 


1. 


14, 


i 


which indicates the 


Diagnostics 
(see Note 3 
of Annex E 


Not applicable 


Address contains 
a non-BCD digit 


Local procedure 
error 


Local procedure 
error 


Prefix digit not 
supported 


Local procedure 
error 


National address 
smaller than national 
address format permits 


Local procedure 
error 


National address 
larger than national 
address format permits 


DNIC less than four 
digits 


Local procedure 
error 


Local procedure 
error 


bits. 7 6%. 6. OF GeCESE 


facility field length 
not set to zero 


Local procedure 
error 


no combination of 
facilities could 
equal facility length 


Facility length Local procedure 


larger than remainder error 
of packets 
Facility values Invalid facility 
conflicts (ex. a request 
particular combination 
not supported). 


Invalid facility 
request 


Facility code not 
allowed. 


Invalid facility 
request 


Facility value not 
allowed or invalid 


Address length Local procedure 


larger than remainder error 

of packet 

Call user data Local procedure 
larger than 128 in error 
case of fast select 

facility 

Class coding of the Local procedure 
facility corresponding error 


to a length of 
parameter larger than 
remainder of packet 


# 67,68 
# 67,68 


# 67,68 


# 67,68 


# 67,68 


# 69 


# 69 


# 38 


# 66 


# 65 


# 66 


# 38 


# 39 


# 69 


16. Facility code 
repeated 


177. The incoming call 
acket indicated 
ast select with 


restriction on response 
c) Clear request packet 


Error Condition 


1. Not applicable 
2. Packet too short 


3. Packet length 
larger than 5 octets error 
(if fast select facility 
not requested) 


4, Non zero address 
length field (if 
fast select facility 
requested) 


Error (d3): The DCE discards the received packet, 
indicates a reset bytransmittingto 


Local procedure # 73 5. Non zero facility Local procedure #75 
error field (if fast select rro 
facility requested) 
Local procedure # 42 
error 
14. Call user data Local procedure # 39 
larger than 128 in error 
case of fast select 
facility (if fast. select 
facility * requested) 
Cause Specific 
Diagnostics 
(see Note 3 15. Clearing cause Local procedure # 81 
of Annex E) field is not "DTE 
originated" in the 
clear request packet 
Local procedure # 38 ; : 
error d) DTE clear confirmation 
Local procedure #39 Error Condition Cause Specific 
diagnostics 
(see Note 3 
of ANNEX E) 
Local procedure #74 1. Not applicable 
error 
2. Packet lengt Local procedure # 39 


larger than 3 3 octets 


State of the interface! 
as perceived by ! 


theDCE oo2e--------------------- ---! 


! Flow 


Packets having a packet !irror #38!Error #38! Discard 
! type identifier which 1Error #33!Error #33! 
is shorter than 1 octet! (d3) ! (d3) ! 
! or is not supported ! ! 
' by the DCE ! ! ! 


Se SBS SFB FF OFS BOS OF | Fe | Seeenae Seeseoewaauntoanes SEs Gea bho Goan e 


TABLE C-4/AX.25 
Action taken by the DCB on receipt of packets in a given 
state of the packet level DTE/DCE interface as perceived 
by the DCE: data transfer (flow control) on assigned 
logical channels 


! 

! 

! 
! Packet’ from ! Control ! Reset ! Reset ! 
eos wich assigne ees Request indi cer tons 
fe a ee IO a Ne | 
! Reset Request ! Normal ! Discard Normal ! 
Os : (d2) ! ) ! 
t DTE Reset lError #27! Error #28! Normal ! 
Confirmation (d3) (d3) (dl) ! 
! Data, interrupt, ! Normal lError #28! Discard ! 
or flow control (d1) ! (d3) ! ! 
! Restart request or DTE lError #41! Error #41! Discard ! 
! restart confirmation ! (d3) (d3) ! ! 
! with bits 1 to 4 of ! ! 
! octet 1 or bits 1 to 8! ! ! ! 
! octet 2 unequal to zero! : 
EE A TS EERIE OE i PE HO RIE 
! 
! 
! 
! 


the DTE a reset indication packet Error 

with the cause "Local procedure error* respectively. 
and the diagnostic xX, and enter 

state d3. For virtual calls, the 


b) If the P(S) 
not valid, t 


received is 
invoke the 
procedure, 


c) The DCE will consider the receipt 


distant DTE is also informed of the 
reset by a reset indication packet, 
with the cause "Remote procedure 
error" (same diagnostic). 


If a reset indication is issued as a 
result of an error condition in state 
d2, the DCE should eventually consider 
(after a time not to exceed 120 
seconds) the DTE/DCE interface to be 
in the flow control ready state (dl). 


Provided none of the following error 
conditions has occured, the action 
taken by the DCE follows the procedure 
as described in sections 4 and 5: 


a) If the packet exceeds the maximum 
permitted length, or is too short, the 
DCE will invoke the Error # 39 or #38 
procedure, respectively. 
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of a DTE interrupt confirmation packet 
which does not correspond to a yet 
unconfirmed DCE interrupt packet as an 
error and will invoke the Error # 43 
procedure. The DCE will either 
discard or consider as an error a DTE 
interrupt packet received before a 
previous DTE interrupt packet has been 
confirmed (Error # 44 procedure). 


d) Not applicable 


e) If the resetting cause. freld.as 
not "DTE originated" in a reset 
request packet, the error procedure is 
invoked A reset indication packet 
will be* transmitted with the cause 
"Local procedure error" and the 
diagnostic # 81. 


ANNEX D D.2 DTE time-outs 


Under certain cirmstances, EAS 
Packet level DCE time-outs and DTE time-outs Recommendation requires the DCE to respond to a 
packet from the DTE within a stated maximum time. 
Table D-Z/AX.25 gives these maximum times. The 
D.1 DCE time-outs actual DCE response times should be well within 
the specified time limits. The rare situation 
where a time-limit is exceeded should only occur 
Under certain circumstances, this when there is a fault condition. 
recommendation requires the DTE to respond to a 
packet issued from the DCE within a stated maximum To facilitate’ -recovery, from. such fault 
time. conditions, the DTE may incorporate timers. The 
time-limits given in Table D-2/AX.25 are the lower 
limits of the times a DTE should allow for proper 
Table D-1/AX.25 covers these circumstances operation. Suggestions on possible DTE actions 
and the actions that the DCE will initiate upon upon. expiration of the time-limits are given ain 
the expiration of that time. Table D-2/AX.25. 
!Time-!Time-! State ! Started ' Normally ! Actions to be taken when the time-out expires ! 
' out ! out ! of the! When ! Terminated few m meme were mn een n nero seem emer me mem eaeceen aes 
! No. ug ues ogres | when ! Local side | Remote side 
3 'channel! ! ! | : 
T10 ! 60 ! x3 ! DCE issues a !DCE leaves the! DCE remains in r3 and may DCE enters the d3 ! 
'secs.! | restart ! r3 state (ex:! issue a diagnostic packet state signalling ! 
! indication | the restart a reset indication! 


a ee ee ee Fe 0 Se ee ee ee | 
1 
1 
t 
1 
t 
- 
t 
t 
{ 
t 
1 


packet ! confirmation 


i] 
I (remote procedure ! 

or restart ! 
§ 


error) ' 
I 
i 


request is 
rece. ag \ 


Vea 


-_ 
t 
t 
t 
( 
i] 
t 
‘ 
i] 
1 
' 
{ 
4 
] 
L) 
_ 
1 
1 
' 
' 
1 
= 
= 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
1 
' 
1 
1 
' 
1 
= 
i) 
t 
1 
t 
1 
t 
1 
t 
1 
t 
t 
t 
t 
t 
i] 
t 
t 
( 
t 
—_ 


Tll ! 180 ! p3 ! DCE issues an! DCE leaves ! DCE enters the p7 state ! DCE enters the p7 ! 
Isecs. ! | incoming ! the p3 state | signalling a clear ' state signalling 
! ! ! call ! (ex: the call! indication (local 1 a clear indication! 
! ! | packet | accepted, ! procedure error) ! (remote procedure ! 
| ! I !clear request, ! ! error) 
| | ! I” or cal | | 
: | request is | 
! ! ! ! received ! | 
fennn- Jeoree- [------- | ene nn nee n----- [---e enn e eee Samana aCraaay aa Torr Lene n nnn en ne ! 
!7T12 ! 60 ! d3 ! DCE issues a ! DCE leaves ! For virtual calls, the DCE! For virtual calls,! 
! isecs «! beset the: ds: state: | enters the p7 state ! DCE enters the p7 ! 
l ! ! ! indication ! (ex: the reset! signalling a clear ' state signalling '! 
l | | | packet ! confirmation |! indication (local | a clear indication.! 
! ! ! ! ! or reset procedure error) ! (remote procedure ! 
I | ! ! ! request is ! | ' 
! ! ! ! !  recetrwmnd, ! | I 
feccwes Veewce fsessccee ioesSostoeeeae ledcutousceuses [==ss-55 tal Pee eee ee eee ee eee eee ~ 
!T13 ! 60 ! p7 ! DCE issues a ! DCE leaves ! DCE remains in p7 and may ! ! 
! 'secs. ! | clear ! the p7 state | issue a diagnostic packet ! | 
I | ! ! indication ! (ex: the clear! I ! 
I ! ! ! packet ! confirmation ! ! ! 
I | ! ! | or clear ! L | 
! ! ! ! ! request is |! ! ! 
! ! ! ! ! received) ! ! | 
Table D-1/AX.25. DCE Time-limits 
! Time-! Time-! State of ! Started ! Normally terminated ! Preferred action to be ! 
| out ! limit!the logical! When | When ! taken when time-limit ! 
!number! value! Channel ! ! ! expires : 
aS int els Ge a” ee a = al nan owas me ee ee ss oe a an ae a ee a ee as aaeneaaasaanannae & “cused cn se a ec es a Ee 
'T20 ! 180 ! r2 ! DTE issues a ! DTE leaves the r2 ! To retransmit the I 
! Isecs. ! ! restart | state (ex: the restart request Y 
' i : request ! restart confirmation! packet I 
| I I ! packet for restart indication! (see Note l I 
! ! ! ! ! is .cenaived)s ! 
{------ {------ !----------- [------ eee eee | an eee nn enn ener wert enn Jee mem een wenn n nn neaaaa-- l 
T2). th 20004 p2 |! DTE issues a ! DTE leaves the p2 | To transmit a clear ! 
| ‘secs. ! ! call request ! state (ex: the call ! request packet ' 
| | | | packet ! connected, clear ! l 
| ! ! ! ! indication, or ! ! 
! ! ! ! 1 incoming call is I ! 
! ! ! ! ! received ! I 
{------ !------ eieteteteteteten wo lee een ene e nee | mem meme nnn ene nner feenwenn aaa -{ 
!7T22 ! 180 ! d2 ! DTE issues a ! DTE leaves the d2 | For virtual. calls; to: | 
! !secs. ! ! reset request! state (ex: the reset.! retransmit the reset ! 
| | ' ! packet {confirmation or reset! request or to transmit ! 
! ! ! ! | indication is revd) a clear request packet 
ieeeese boteese igeceococees locecuaewee meas Piocosuseceneteseaasse bso tcessleceuesoeeceess ae 
! T23 ! 180 ! P6 ! DTE issues a ! DTE leaves the p6 ! To retransmit the ! 
| 'secs. ! ! clear request! state (ex: the clear! ees re oan acket ! 
| ! ! ! packet fconfirmation or clear! (see Note ! 
| | | ! ! indication is revd) ! ! 
Note 1: After unsuccessful retries,, recovery decisions should be 


taken at higher levels. 


Note 2: Afte 
cons 


r unsuccessful retries, the logical channel should be 
idered out-of-order. The restart procedure should only 


be invoked for recovery if reinitialization of all logica 


chan 


nels is acceptable. 


Table D-2/AX.25. DTE Time-limits 
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ANNEX E 


Coding of AX.25 network generated diagnostic fields in clear, reset, and restart indication and 
diagnostic packets (see Notes 1, 2, and 3) 


! Diagnostics ! Bits ! Decimal ! Hex ! 
! 187654321 
! No additional information !00000000! 0 foo ! 
! Invalid P(S ‘ro00o00qg0ddi! 1 'o1 ! 
{ Invalid P(R ro000gq0d0010! 2 !o2 ! 
PeoWe goer ee Goa enw ew eee n nn | ----------------- | a-------- |----- ! 
| Packet type invalid 100010000! 16 #$!10 ! 
| For state rl 100010001! 17 !11 ! 
For state r2 100010010! 18 !12 ! 
For state r3 'o00010011! 19 ee ts ee 
For state pl 1oo0do01ld1ldOdO! 20 114 =! 
For state p2 1900010101! 21 ri5 ! 
For state p3 1raaoloi1ii10! 22 !16 ! 
For state p4 ‘00010111! 23 !17 ! 
For state p95 'o0d01l11000! 24 ' 18 ! 
For state p6 190011001! 25 ea oe 
For state p/ roo0og1lLOLO! 26 ' 1A ! 
For state dl 1on0dlliotlilitl! 27 ' 1B! 
For state d2 1oo0o1LILLOO! = 28 be TG? J 
For state d3 '00011101! ~= 29 ! 1D ! 
(not implemented) 100011110! = £30 ! JE 
eee pipe eaagseearees O00 1 AA ee RI 
! Packet not allowed lrcrorrouooor! 32 | 20! 
! Unidentifiable packet 100100001! 33 P21 
! (not implemented 100100010! 34 ' 22 1 
! (not implemented 1900100011! = #35 !23 ! 
! Packet on unassigned ! ! ! 
! logical channel 100100100! 36 124 ! 
(not implemented) 1oog01oolotlt:! 37 E25. if 
! Packet too short 'oo01l1l00d0110! 38 126 ! 
! Packet too long 'oo0lo00d0111! 39 !27 
| Invalid General Format Ident! 00101000! 40 ! 28 ! 
! Restart with non-zero in i ! ! | 
; pene in LCGN or LCN } 00101001 41 : 29 
! Packet type not compatible :; : 
wey eset Lia 100101010! 42 &! 2A! 
! Unauthorized interrupt ! ! | ' 
! confirmation 100101011! #43 ! 2B ! 
! Unauthorized interrupt 'oo0ld01100! 44 ! 9¢ ! 
' (not pip Tone ntes 100101101! 45 ! 2p ! 
! (not implemented '00101110! £4446 ! ! 
00101111 } 47 i 2F : 
! Time expired (00110000! £=48 ! 30 ! 
| For incoming call ‘ro0lLOadOIL! 49 ! 31 ! 
| For clear indication 'o00110010! #50 a 
| For reset indication 100110011! #51 1.33. 
| For restart indication 100110100! 52 P34 4 
i : 00111111 ! 6 3 i 3F ‘ 
! Call set-up or clearin ! ! | 
, “Ssroblems— 9 101000000! 64 !40 ! 
boc code not allowed 01000001 ! 65 ! 41 ! 
! Facili arameter : ji : : 
| not a towed '01000010! 66 !42 ! 
! Invalid called address 'o100d00d00d11! 67 143 ! 
! Invalid calling address 'ro01000100! 68 144 ! 
! Invalid facility length 101000101! = £69 145 ! 
! (not implemented) '01000110! 70 146 ! 
! No logical channel available! 01000111! #71 147 ! 
! Call collision ro1d001000! 72 148 ! 
! Duplicate facility requested! 01001001! 73 149 ! 
! Non-zero address length 101001010! 74 14a ! 
! Non-zero facility length 101001011! 75 14B ! 
non-assigned up to: 01001111 } 79 4F 
! Miscellaneous 101010000! 80 !50 ! 
! imp repo cause code from DTE! 01010001! 81 !51 ! 
! not implemented) !'01010010! 82 152 ! 
!Inconsistant Q bit setting !01010011 ! 83 153 ! 
! Maintenance action '01010100! 84 154 ! 
non-assigned up to: ; 01011111 95 : 5F 
! Not assigned from : 'o11d0e0000! 96 160 ! 
! 0: oOo 2 Te he 2 197 7° 
temcaueriudsewaSs—sseeceseseeeeee (Juedeseweeseuees (Jos eeeee fsocce { 
! Reserved for network 110000000! 128 80: 
! specific diagnostic i Wie Ela Ea 255 
! information ! 1111 i PEs ot 
Note 1: Ne Pee aotoe ae codes need apply to a specific network, Put those used are coded as shown in 
e table.- 
Note 2: A given diagnostic need not apply to all packee types (ex: reset indication, clear indication, 
restart indication, and diagnostic packets 
Note 3: The first diagnostic in each grouping is a generig diagnostic and is used when'more specific 
diagnostics are not defined within the grouping. he decimal 0 diagnostic code can be used in 


Situations where no other diagnostic applies. 


3.52 


ANNEX F 
Address coding techniques for AX.25 
Background 
The oo information will be called 
Appendix 1 of AX.25 in the future, in order to 
prevent conflicts with CCITT additions. 


Address field description in AX.25 


The following restrictions apply to the 
address field -of X.25- packets (Sectron. 5./2.322%2) « 


When present, octet 7 and the following 
octets consist of the called DTE address when 
present, then the calling DTE address’ when 
present. 


Each digit of an address is coded in a 
semi-octet in binary-coded-decimal (BCD) with bit 
5 or bit 1 being the low order bit of the digit. 


Starting from the high order digit, the 
address is coded in octet 7 and consecutive octets 
with two digits per octet. In each octet, the 
higher order digit.its: gcoded in: bits 8, T, -6;; and 
5s 


The address field shall be rounded w to 
an integral number of octets by inserting zeros in 
bits 4, 3, 2, and 1 of the last octet of the field 
when necessary. 


Data Network Identification Code 


CCITT recommendation X.121 specifies a 
method of creating an international numbering plan 
for public data networks. Part of this 
recommendation specifies the assignment of a four 
digit number to identify public data networks. 
This number 1s called the Data Network 
Identification Code, or DNIC. 


The first three digits of the DNIC is 
used as a country.code, and is called the Data 
Country Code (DCC). The fourth digit is used to 
identify the public network within the country, 
and is called the network digit. 


The CCITT has the responsibility for 
assigning the DCC, a list of assigned DCC numbers 
is listed in x.121. The first DCC for the United 
States is 310. 


The responsibility for assigning network 
digits is left to the responsible body within the 
country in question. The Federal Communications 
Commission is the responsible authority in the 
United States. Unfortunately, tie PCC 1S... 11Gk 
assigning network digits at the moment, so the 
amateurs are unable to have assigned a DNIC code 
to us for now. We will attempt to have assigned 
to the amateur network a DNIC number’ when 
possible. 


For now, room should be left for the 
DNIC number, primarily to allow internetworking 
with existing public data networks. 


Original DTE address techniques for AX.25 


When the AX.25 draft committee originally 
met a method of coding the amateur station 
calisign into the DTE calling and DTE called 
fields of call request, incoming call, call 
accepted, and call connected packets. This 
involved coding the Data Network Identification 
Code (DNIC), a station subaddress, and the amateur 
call of each DTE into seven octets as follows. 


The DNIC is a four digit number, and as such, 
would fit into the first two octets. The first 
semi-octet of the first octet would carry the 
first digit, with the three succeeding digits in 
the next three semi-octets. 


The third octet would contain a five bit 
field used as a substation address. This field 
would be binary coded in bit. positions 1 thru. 5, 
with bit i being the LSB. Bits 6, 7, and 8 are 
reserved at this time, and set to zero. 


The fourth through seventh octets contain the 


amateur station ca Esiét Since there is. not 
enough room to contain the callsign directly, is 


was recommended that the callsign be coded so that 
oP to six callsign characters could be fit into 
the four octets using Radix 50 coding. Radix 50 
coding allows three upper-case alpha or numeric 
characters to fit into a six octal digit field. 
The fourth octet would contain the first portion 
of the radix-—50 encoded characters, with 
succeeding octets carrying the rest of the 
information in order. If a callsign contained 
less than six ASCII characters, trailing ASCII 
space characters would be added as necessary. 


It should be noted that the above method of 
coding could create illegal (not BCD) addressing 
information, which could cause problems at an 
interface to a public data network. 


New method ‘OF addressing in AX.25 packets 


Information has just reached me (as I am 
printing this paper) that at a recent meeting, the 
CCITT has added new methods of coding address 
information into X.25 packets. Some of the 
additions follow immediately, then comments by the 
author on how to use these new methods. 


AX.25 Additions 
Facility Markers 


In the third paper of this series, under 
section 7.4.1, delete the last four paragraphs, 
and add the following: 


In addition to the facility/registration 
codes defined in section 7, other codes may be 
used for 


-non-AX.25 facilities aeatieran | provided by 
some network(s) (call set-up packets 


-CCITT-specified DTE facilities as described 
in Annex G of this recommendation (call set-up, 
clear request and clear indication packets). 


Facility/registration markers, 
consisting of a single octet pair, are used to 
separate requests for AX.25 facilities as defined 
in sections 6 and 7 from other categories as 
defined above, and, when several categories of 
facilities are simultaneously present, to separate 
these categories from each other. 


The first octet of the marker is a 
facility/registration code and is set to zero. 
The second octet is a facility/registration 
parameter field. 


The facility registration parameter 
field of a marker is set to zero when the marker 
precedes requests for: 


-non-AX.25 facilities provided by the network 
in case of intranetwork calls (call set-up 
packets). 


—-non-AX.25 facilities provided by the network 
to which the calling DTE is connected, in case of 
intranetwork calls. 


The facility parameter field of a marker 
is set to all ones when the marker precedes 
requests for non-AX.25 facilities provided by the 
network to which the called DTE is connected, in 
case of intranetwork calls (call set-up packets). 


The facility parameter field of a marker 
is set to 00001111 when the marker precedes 
requests for CCITT-specified DTE facilities. 


All networks will support the facilit 
markers with a facility parameter field set to al 
ones or 00001111. 


DTEs should not use a facility marker 
with a facility parameter field set to all ones in 
case of intranetwork calls. however, if a DTE 
uses such a marker in an intranetwork call, the 
DCE is not obliged to clear the call, and the 
marker, with the corresponding facility requests, 
may be transmitted to the remote DTE. 


Facility/registration codes for AX.25 
facilities and for the other categories of 
facilities may be Simultaneously present. 
However, requests for AX.25 facilities must 
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precede the other requests, and reqiests for 
CCITT-specified DTE facilities must follow the 
other requests. 


The coding of CCITT-specified DTE 
facilities should comply with the description in 
Annex G. However, it is not required for the DCE 
to verify that compliance. If the network 
verifies that cot peeence and finds an error, it 
may clear the ca fl. The CCITT-specified DTE 
facilities are passed unchanged between the two 


packet-—mode DTEs. 
(end of addition to7.4.1) 
ANNEX G 


CCITT-specified DTE facilities to support 
the OSI network service 


G.1l Introduction 


The facilities described in this Annex 
are intended to support end-to-end signalling 
required by the OSI network service. They follow 
the SS ee hy DTE facility marker defined in 
section 7.4, These facilities are passed are 
Bae oe uncangee between the two packet mode DTEs 
involved. 


Procedures for use of these facilities 
by DTEs require definition by international user 
bodies. Subsequent provision ofX.25 facilities 
to be acted on b ublic data networks is for 
further study. do ing for these facilities is 
defined here in order to facilitate a consistent 
facility coding scheme in such future evolution. 


G.2 Coding of the CCTTTI-specified facilities 
eels Calling address extension facility 


The calling address extension facility 
is used in call request and incoming call packets 
to convey additional calling DTE address 
information. 


Go2clied foding of the acility code field 


The coding of the facility code field 
for the calling address extension facility is: 


bits: Od Ge Bere Bo 2 
code de 00 L000 


Codin Of .the- Pacalaty parameter 
field 

The octet following the facility code 
field indicates the length in octets of the 
facility parameter field and has a value of n+ 1, 
where n may be a maximum of 16 octets in order to 
hold the calling address extension. 


@ 


The first octet of the facility 
parameter field indicates, in bits 6, 5, 4, 3, 2, 
and... Ehe. number Of “semi—octets (up: to 32) 2n the 
calling address extension. This address length 
indicator is binary coded, and bit 1 is the low 
order bit. Bits 8 and 7 of this octet are set to 
Zero. 


The following octets (up to 16) contain 
the calling address extension. 


Each digit of an address is coded in a 
semi-octet in ery coded decimal, where bit 5 or 
1 is the low order bit of the digit. 


Starting from the high-order digit, the 
address is coded in octet and consecutive 
octets of the foo parameter field with two 
digits paer octet. n each octet, the higher 
order digit is coded in bits 8, 7, 6, and 5. 


When necessary, the eee | parameter 
field shall be rounded up to,an integral number of 
octets by inserting zeros in bits 4, 3, 2, and 1 
of the last octet of the field. 


Ge2e2 Called address extension facility 


The called address extension facility is 
used in call request, incoming call. call 
accepted, call connected, clear indication, and 
clear request packets to convey additional called 
DTE address information. 


G22 1 Coding of the facility code field 


The coding of the pact} ity code field 
for the called address extension facility is: 


bits: 8 /6- > 4°32 1 

code ¢ tL 1-0) 0 250" 0-1 
Coding of the facility parameter 
field 


The octet following the facility code 
field indicates the length in octets of the 
facility parameter field and has a value of n+ 1, 
where n may be a maximum of 16 octets in order to 
hold the called address extension. 


The ‘fivst octet of the» tfacriity 
parameter field indicates, in bits 6, 5, 4, 3, 2, 
and 1, the number of semi-octets (up to 32) in the 
called address extension. This address length 
indicator is binary codes, and bit 1 is the Tow 
order bit. Bits 8 and 7 of this octet are set to 
zero. 


The following octets (up to 16) contain 
the called address extension. 


Each digit of an address is coded in a 
semi-octet in binary coded decimal, where bit 5 or 
1 is the low order bit of the digit. 


Starting from the high-order digit, the 
address is coded in octet and consecutive 
octets of the facility parameter field with two 
digits paer octet. n each octet, the higher 
order digit is coded in bits 8, 7, 6, and 5. 


When necessary, the facility parameter 
field shall be rounded up to an ae a number of 
octets by inserting zeros in bits 4, 3, 2, andl 
of the last octet of the field. 


AX.25 marker definitions 


In order to make clear the various markers 
that might be in the facility field, they are 
listed below. Once again these markers are used 
to separate the various types of facilities that 
might appear in call generation packets. 


Facility marker for calling network facilities 


This marker soenstaes facilities following it 
are to be provided by the calling DTE network. 


bis: 82 16..5° 4 -3)2 
OGLEtL: O70) 0200? OrO:'0 
octet2: OE 6 as Se 6 i Ga 6 ake 6 oa 6) 


Facility marker for called DTE_network facilities 


This marker signifies facilities following it 
are to be provided by the called DTE network. 


bits: GF 46 Ss AS aL 
octetl: Glee © es 6 eat eee 8. 
octet2: A ode od, od, 2 SL DE 


Facility marker for CCITT-specified facilities 


This marker signifies facilities following it 
are CCITT-specified facilities. 


bits? ol iD ofa nc! mec ame I 
octetl: GS 6 Rs @ as 6 cae fee @ fee 0 fea 
octet2: O-0:.0..0) 1 1-1-1 


This marker signifies facilities following it 
are amateur radio network provided facilities. 


bits: Se ie oie ee ae eae 
octetl: 00000000 
octet2: A ae ele Sele ale ah ah 


Note: The amateur facility marker has been 
changed, since the CCITT has added a marker using 
the original code that the AX.25 draft committee 
used. The choice of 11111110 is being made in 
hopes that the CCITT will stay away from this 
code, since the code 11111111 has been used. 


3.54 


Coding of amateur addresses in AX.25 


The following is recommendation on codin 
of the calling and Salad DTE address fields an 
using the calling and called extension facilities 
in an amateur AX.25 network. 


Coding of the_DTE address_fields 


If the actual DTE addresses are conveyed 
in the newly created calling and called address 
extension facilities, this leaves the DTE calling 
and DIE called address fields available for other 
uses. One use for these fields might be to convey 
geographical location information of the DTEs 
Involved, which might help call routing decisions. 


If we leave the first two octets for the DNIC 
number (four digits coded per AX.25 section 6.2), 
this leaves room for up to 5 octets (10 digits) of 
additional information. One Se een would 
be to use the VHF grid location system. 


One of the problems with the VHF grid system 
is that it uses alpha characters in the first two 
characters, and numeric characters of the last two 
characters of the coarse location, and two more 
alpha caharacters in the two additional characters 
used in the fine grid location system. Since 
AX.25 specifies binary coded decimal format digits 
in the address fields, ASCII characters could 
create invalid DTE addresses. 


A suggestion to avoid this problem is to 
break up the alpha characters into two portions, 
each representable in binary coded decimal format. 
If an ASCII character (upper case alpha, or 
numeric only) is divided so that bits 1, 2, and 3 
are conveyed in the low order digit, and bits 4, 
5, and 6 are conveyed in the high order digit, an 


ASCII character could be represented in one octet, 
while still keeping to the Hl2tter of X.25 


Using this technique, the first two octets 
would convey the DNIC number, the third octet 
would convey the first alpha character of the VHF 
grid system, the fourth octet would have the 
second alpha character, the fifth octet would have 
both digits of the grid system identifier. The 
Sixth and seventh octets would carry the fine 
resolution alpha characters of the grid 
information. 


Address extension field coding 


The addition of the calling and called 
address extension facilities has allowed a re- 
thinking of amateur address coding. As the 
description of these facilities above shows, the 
CCITT is still considering addressing information 
to be numeric onl The United States contigent 
hoping that this linitation can be eliminated, 

owever. 


Anticipating this... loosening—up- of “che 
restriction, I recommend that the extended address 
coding consist of the amateur callsign of the 
station involved, consisting of the six upper-case 
alpha or numeric characters, followed by an 
additional octet carrying a substation 
identification number. this substation 
identification number should be five pas long 
binary coded, and reside in bits 5, 4, 3, 2, and t 
of the seventh octet of the address field. Bits 
8, 7, and 6 are reserved at this time, and set to 
zero. 


This coding scheme will allow the amateur 
callsign to be used as a unique station 
identifier, just as it is in Level 2 of AX.25 
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An Enhanced Terminal Node Controller 


by Lyle Johnson, 


WA7GXD 


President 
Tucson Amateur Packet Radio 
PO Box 22888 
Tucson AZ 


ABSTRACT 


This paper describes changes made in the 
Terminal Node Controller (TNC) developed 
by Tucson Amateur Packet Radio (TAPR) as a 
result of extensive field evaluation dur- 
ing the TAPR Beta test. 


BACKGROUND 
Tucson Amateur Packet Radio is a non- 


profit Research and Development group with 
over 700 members worldwide. During 1981- 


1982, a complete, self-contained Terminal 
Node Controller was developed. During the 
period of January, 1983, through June, 


1983, over 170 preassembled TNCs were 
placed in more than 19 sites worldwide for 
testing and evaluation. 


The testing revealed many things beyond 
the evaluation of the TNC: primary among 
this list is the finding that non-technic-— 
ally oriented Amateurs were both interes- 
ted in Packet radio as a mode and capable 
of placing a Packet station in operation. 


Another important observation was that a 
volunteer group would quickly reach burn- 
out if the participants were required to 
assemble and test each and every TNC prior 
to shipment. This observation, along with 
tightened FCC type classifications under 
Part 15 for manufactured equipment, led 
TAPR to the first major change in the Beta 
TNC for general distribution -- the new 
TNC would be in the form of a kit. 


THE BETA TNC 


TAPR's first generally distributed TNC 
design has become known as the Beta Board. 
This device was based on the 6809 micro- 
processor, included 6k-bytes of RAM, 24k- 
bytes of EPROM, 64 bytes of non-volatile 
memory (NOVRAM), a Western Digital HDLC 
controller, serial and parallel ports, an 


on-board 120@-baud radio modem with watch- 
dog timer, built-in regulated AC power 
supply and a generous wire-wrap area for 
the experimenter. 


Software was written in the PASCAL lan- 
guage for high-level functions, with low- 
level routines written in 6809 Assembler. 
The software design was accomplished by a 
team scattered between Tucson and the Los 
Angeles area, while the hardware design 
was effected in Tucson. 
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A comprehensive manual was written and 
distributed with the Beta Board; it con- 
tained nearly 200 pages of descriptions, 
operating procedures, interfacing data, 
protocol definitions and general Packet 
radio background information. 


THE KIT TNC:_ DESIGN EVOLUTION 


The response of the Amateur community to 
the Beta Board was overwhelmingly posi- 
tive: nonetheless, there were some minor 
difficulties reported. In addition, TAPR 
wanted to increase the flexibility of the 
TNC to more easily accommodate the antici- 
pated users of PACSAT, HF, METSCAT, OSCAR 
10 and others. Finally, the unit had to be 
designed in such a way as to allow assem- 
bly and calibration by the less technical- 
ly oriented members of the Amateur frater- 
nity to help encourage the growth of the 
mode through on-the-air application. 


A few users found the non-polarized con- 
nectors used on the Beta Boards to be a 
problem. Worse, the radio input/output 
(I/O) and power transformer disconnect 
used identical connectors. The solution to 
this problem meant a different form factor 
for the board: this provided the opportun- 
ity to include subtle changes to the TNC's 
hardware design since a completely new 
printed circuit (PC) board would have to 
be laid out. 


Field feedback coupled with local experi- 
ence on the part of the software design 
team led to suggestions for improved per- 
formance and an even more friendly user 
interface. Naturally, this meant an in- 
crease in the standard program code stor- 
age capacity (from 24k-bytes to 32k- 


bytes) ! 


The documentation would require a complete 
rewrite. The operating section would have 
to reflect new commands and capabilities. 
The circuit descriptions would have to be 
revised. And a detailed assembly manual 
would have to be written and field-tested. 


roughly defined, it was 
time to go to work! During the next few 
months of intensive effort, the design 
team kept true to the premise that 


The opportunities 


"the sooner you get behind in a proj- 
ject, the more time you have to catch 
up! a 


HARDWARE ENHANCEMENTS 
The TAPR kit INC offers 8k-bytes of RAM 
(up from 6k-bytes on the Beta Board) as 
standard. The Program storage has’ been 


increased from 24k-bytes to 32k-bytes. In 
addition, through the use of an 8k-byte 
Single chip static RAM chip (TAPR waS one 
of the very first US corporations to use 
this IC), an empty memory socket iS pro- 
vided with jumper options to allow the use 
of any JEDEC "bytewide" memory IC from 2k- 
through 32k-bytes in capacity. The memory 
decoding circuitry iS pre-programmed to 
accommodate a 16k-byte part in this site. 
Thus, the TNC can utilize up to 56k-bytes 
of memory without any modification what- 
soever! 


Nonvolatile RAM (NOVRAM) has been in- 
creased from 32 bytes to two "banks" of 64 
bytes each. This non-battery backed memory 
technology allows the TNC to store call- 


Sign, terminal parameters, radio link data 
and similar information indefinitely with- 
out requiring the operator to manually 
enter them each time the unit is powered 
up, or forcing the operator to utilize 
very conservative default values for the 


link that are not optimum for his particu- 
lar local area network. 


To simplify interfacing the serial I/O 
port to ((three-wire" RS-232 devices, de- 
fault pullup resistors have been included 
to eliminate the need for jumpers, yet 
provide hardware handshaking for those 
attached devices that can support CTS/RTS 
and DTR/DSR- protocol. As with the Beta 
Board, true RS-232-C levels are implemen- 
ted on the serial port, although the TNC 
can communicate with devices that utilize 
TTL output levels. 

The power supply circuitry utilizes 3 amp 


diodes in the 5-volt supply and the elec- 


trolytic filter capacitors are much fur- 
ther from the heatsink to slow the drying 
of the electrolyte that normally occurs 
with time. The negative voltage regulators 
are more heavily bypassed to suppress any 
tendency towards oscillation. Finally, a 
separate 5-volt regulator and ground re- 
turn path is provided to the on-board 
modem for more complete noise rejection. 


The 5=-volt regulator IC and heatsink are 
wired in such a way as to allow easy 
relocation off-board in the event a cabi- 
net is used while allowing on-board opera- 
tion if the TNC is not enclosed. A Molex 
connector is provided for the power trans-— 
former disconnect: a redesigned power 
transformer is included with multiple line 
voltage taps for best efficiency. 


The clock oscillator frequency has’ been 
doubled and a jumper provided to allow 
operation of the digital circuitry at a 


faster rate in the event high-speed packet 
operation (greater than about 9600 bauds) 
becomes commonplace. 
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Link status is output on the parallel port 
in the default condition: this allows 
easier interfacing to "host" computers 
that may have one or more Slave TNCs at-— 
tached for bulletin board and other ser- 


vices. 


A standard DB-25S connector is provided on 


the TNC for the serial portandthe TNC is 
configured as "Data Communications Equip- 
ment'" (pc—E) -- it appears as a standard 


modem to an attached terminal or computer. 


A DB-25P connector is used to interface to 
the parallel port, while a DE-% connector 
is included to attach a radio to the TNC. 
The pinout of the DE-9 is such that, if 
ribbon cable is used and attached to all 
nine pins (as would occur if an insulation 
displacement connector were used), alter- 


nate leads will be grounded for good sig- 
nal separation and shielding. 


The 
mind; 
rations 


TNC waS designed with a cabinet -in 

In addition to the heatsink conside- 
mentioned above, there is a com- 
plete "front panel" disconnect on the 
unit. A 16-pin IC socket located immedi- 
ately behind the front panel of the cabi- 
net repeats all on-board LED functions as 
wel 1 as all DIPswitch connections. The 
LEDs have their own current limiting re- 
Sistors. 


LED monitored functions have been in- 
creased from those on the Beta Board. In 
addition to received audio input level 
monitoring and transmitted data, there are 
monitors for data -carrier “detect (very 
useful for HF and OSCAR operation), CWID, 
PTT, HDLC RESET and SPARE (user configur- 
able). The switch functions have been 
increased and include ROM/NOVRAM default 
parameters, NOVRAM BANK SELECT (for multi- 
ple operator or multiple function sta- 
tions), NOVRAM DISCONNECT (for rebooting 
with "non-permanent" parameters) and, of 
course, RESET. 


The area that received the greatest atten- 
tion in the hardware rework effort was the 


modem. This is perhaps the most critical 
part of the entire TNC hardware. 

With flexibility and performance as_ the 
bywords, the modem design -was picked apart 
by several people and extensively tested. 
The results of these investigations were 
consolidated and incorporated in the new 
TNC design. 

Careful rework of the power supply and 


power distribution on the hoard resulted 
in a reduced noise floor for the modem. 
Increased physical separation of the modu- 
lator and demodulator reduced crosstalk 
tendencies. Post filtering of the MF-12 
switched capacitor filter by an op-amp 
removed high frequency switching tran- 
sients from the input to the XR2211 PLL 
demodulator. The demodulator can be com- 
pletely reconfigured (for 300 baud HF 
work, for example) by swapping a 16-pin 


DIP header plugged into a standard IC 
socket. This encourages experimentation 
with other shifts and data rates for opti- 
mizing communications over a given path. 


As with the Beta Board, the MF-10 filter 
is defined via a plug-in DIP header con- 
taining only resistors. Similarly, the 
XR2206 phase-coherent FSK modulator is 
configured via a 14-pin DIP plug-in hea- 
der. 


One of the (apparently) least understood 
causes of problems with Packet signals is 
due to overdrive of the microphone ampli- 
fier circuitry in the associated radio. 
The Beta Board used the output of the 
"2206 modem (buffered by an op-amp with 
unity gain) to feed the radio directly. 
This resulted in a rather critical setting 
of the audio output adjustment trimmer 
near the low end of its rotation. The new 
TNC includes a 3@:1 attenuator to provide 
a greater usable adjustment range and 
minimize the possibility of overdrive to 
the attached radio. 


The radio PTT circuitry is now based on a 
power FET. Unlike the Darlington transis- 
tor keying circuit used in the Beta Board, 
with its 0.6 volt minimum level when "on," 
the new TNC has an effective "on" resis-— 
tance in the keying circuit of about 4 
ohms. The "off" voltage can be nearly 36 
volts as well. TAPR has not received a 
report to date of anyone having trouble 
keying any common radio with this new 
Circuit: several late model radios would 
not tolerate the standard Beta circuit. 


The watchdog timer can be reconfigured via 
the modulator header. This allows easier 
interfacing with HF and other radios that 
typically use lower data rates on the air. 
The default timeout was increased from 
about 15 seconds to about 1 minute for 
Similar reasons. 


The calibration circuitry for the modem 
was revised. The XR2211 has an unusual 
waveform that many commercial frequency 
counters won't accept: the Beta Board 
waveshaping circuit only worked for about 
60% of the TNCs. The kit TNC includes a 
Schmitt trigger in the wave shaping cir- 
cuit that drives the on-board counter: 
this has proven effective in every case 


that the author is aware of. 


The CWID is now done via FSK rather than 
tone on-off keying. This prevents a lis- 
tening TNC from mistaking the pause be- 
tween letters ina call sign for a free 
channel and "colliding" with the remainder 
of the CWID. Further, the TNC suppresses 
the audio output from the '2206 modulator 
when it is not attempting to key the 
transmitter: this allows the user to use 
voice override without disconnecting the 
TNC from the radio. 


Of course, no matter how good the modem 
is, others will want to try their own 
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designs. This being a goal of TAPR's, a 
complete modem disconnect is provided on 
the kit INC. Utilizing a standard IDC 28- 
pin polarized connector, it is a simple 
matter to reconfigure the TNC to use an 
external modem. This is desirable when 
experimenting with radio link data rates 
in excess of 1200 baud, or when using a 
scheme other than (A)FSK for modulation. 
SOFTWARE ENHANCEMENTS 

The added memory space for program storage 
allowed the already friendly user-inter- 
face to become friendlier. 


Several commands now have more flexible 
arguments: for example, the DISPLAY com- 
mand, which used to dump all user-alter- 
able parameters, now may optionally show 
only those parameters that relate to a 
specific use, such as terminal character- 
istics. 


TAPR took the liberty to allow multiple 
digipeaters to be specified in AX.25 mode. 
The Beta software allowed up to three 
"hops" while the new kit software allows 
up to eight! While digipeaters are a bit 
of a kludge to a "pure" level two, they 
have proven invaluable during this early 
phase in the development of packet radio 
and the multiple hop concept has been 
invaluable in many areas that otherwise 
would be cut off from "local" activity. 


Link status is now output on the parallel 
port. This was provided in response to 
numerous requests from users who wanted to 
interface bulletin boards and other "host" 
computer applications. 


Baud rates for both the terminal and radio 
ports are now specified by the data rate 
(e.g, 1200) rather than by a table lookup 
value (e.g., 8). Similar human factors 
improvements have been made in specifying 
many other parameters. 


The suppressable CWID may now include text 
instead of simply the station call sign. 


Beacon text and non-connected-mode packet 
transmissions may now specify up to eight 
digipeaters in their output routing. 


To provide greater compatibility with 
users of the VADCG board, special options 
were included to allow the sending of CR 
and LF characters as well the methods of 
receiving them. 


In addition to the standard RTTY-like 
CONVERSE mode, a full "transparent" mode 
of operation, proven on the Beta Boards, 
is retained for such tasks as computer-to- 
computer file transfers. 


A special full-duplex mode (the TNC always 
operates in a full-duplex mode on both the 
radio and serial I/O ports) has been in- 
cluded for use on OSCAR 10 and other very 
noisy environments. 


Support for the TAPR EPROM programming 
adapter is included in the software. This 
allows duplicating the TNC software for 
field updates and the like. Using the 
INTEL "intelligent" programming algorithm, 
2764s are typically programmed in 1-1/2 
minutes and 27128s in under 3 minutes. 


The above serve as examples of the exten- 
Sive software effort associated with the 
release of the new TNC kit -- there are 
many more changes, some very subtle, which 
contribute to the ease of use and general 
acceptance of the device. 


Of course, with the exception of the EPROM 
programmer support, a set of EPROMs that 
incorporate the full "Version 3" software 
enhancements is available for use on un- 
modified Beta Boards modified Beta 
Boards can use kit software. 


DOCUMENTATION 


The TNC manual was extensively revised to 
include full operating details for the new 
software. A tutorial-like "front-end" was 
added to the operations section for the 
first-time user who is not in an area 
where there is other local Packet activi- 


ty* 


The largest single "new" effort in the 
manual, however, was in writing the assem- 
bly instructions. The instructions had to 
be sufficiently detailed to allow a rela- 
tively inexperienced constructor to assem- 
ble, calibrate and verify the operation of 
the TNC. 


While not often considered as documenta- 
tion, the PC board had to be silk screened 
in a non-ambiguous manner and keyed to the 
manual in such a way as to reinforce the 
accuracy of assembly and, hopefully, as- 
Sist in locating assembly errors and later 
troubleshooting during the useful life of 
the TNC. 


The manual organization was carefully 
considered and a looseleaf notebook format 
with tabbed index dividers was developed. 
The result is an easy-to-use reference for 
Packet station operation along with a 
clean appearance. 


BRET: LES 


In the late summer of 1983, the kit TNC 
was ready to be tested. Two "Rev 1" TNCs 
were built and evaluated. After numerous 
delays (if anything can go wrong, it 
will), twenty "Rev 2" test kits were sent 
to carefully selected participants in ear- 
ly October. The testers were asked to 
build the kits, evaluate the instructions 
(the manual was very preliminary, as was 
the software) and give a detailed report 
on the overall "kit-ability" of the unit. 


The response was gratifying. Every kit 
worked! Valuable insight was gained into 
the assembly process, the directions were 
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revised and the graphics taken to a com- 
mercial firm for finalization. 


PRELIMINARY FIELD RESULTS 


Over the period from November, LISS 
through early March, 1984, TAPR shipped 
over 500 kits. None have been returned for 
repair, although several dedicated pac- 
keteers in a few locations have assisted 
other locals in getting some kits up and 
running. 


Special MF-10 filter resistor packs have 
been developed and used successfully for 
routine HF and OSCAR-10 communications. 


Packet QSOs with TNCs of other manufacture 
have been made regularly, the only diffi- 
culties being in the non-uniform implemen- 
tation of the "Poll/Final" bit of the 
AX.25 protocol specification. 


Various bulletin board systems have been 
successfully interfaced to the INC. Radios 
of many types and computers/terminals of 
various manufacture have been connected 
with minimal difficulty. 


Experiments with the on-board modem have 
resulted in solid copy over marginal paths 
at 1200 baud; 1800 baud operation has been 
regularly achieved over very good paths. 


CONCLUSIONS 


The development of the TAPR TNC kit was a 
very challenging experience to those in- 
volved. The TNC itself has been widely 
accepted in the Amateur community; the 
fact that it is a complex piece of equip- 
ment offered only in kit form has not 
seemed to restrict that acceptance. 


An extensive refinement of the Beta Board 
tested during 1983, the TNC represents the 
unselfish efforts of hundreds of Amateurs 
worldwide to help usher in an era of er- 
ror-free digital communications for the 
Amateur community at large. 
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ABSTRACT 


Comparisons are made between commercial 
packet-switching applications and the 
unique Amateur radio environment. Sugges- 
tions for enhancing the AX.25 Level Two 
protocol are given. 


BACKGROUND 


In October, 1982, a special meeting was 
held in conjunction with the AMSAT Annual 
Meeting to define a Level Two protocol. 
Representatives from many Packet groups 
were present, and adopted a modified ver- 
Sion of the AMRAD-sponsored AX.25 Level 
Iwo” “prOococol. 


Since that time, AX.25 has become the de 
facto standard Level Two protocol in the 
United States and many other countries. 


Tucson Amateur Packet Radio (TAPR) imple- 
mented this new protocol (with a few not-— 
able extensions) in December, 1982, on its 
then-current "Beta" Terminal Node Control- 
ler. These devices saw widespread distri- 
bution beginning in January, 1983. 


Since that time, over 700 TAPR TNCs have 
been placed in the field and the exten- 
Sions have had widespread acceptance. With 
experience have come requests for certain 
other changes to the protocol these 
requests form the basis of this paper. 


COMMERCIAL APPLICATION 
X.25 (the basis for AX.25) is used in 
commercial packet-switching networks. 


There are specific features to this proto- 
col that allow for such things as asses- 


Sing connection charges and the like, but 
a primary philosophical factor reflected 
in the protecol dis «that of “point-to- 


point" connections. 


To expand on this thought, X.25 assumes 
that the "terminal node," or user, is 
connecting to a "host," or master, node. 
All communications to and from the user go 
through this host. This, of course, makes 
it easy for the host to log connect time 
and otherwise supervise the network so 


each user gets his bill on time! 


Another feature allowed in X.25 is the so- 
called "balanced mode," where two nodes 
are connected as equals; there is no mas- 
ter/slave connotation. This is the mode 
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that has been adapted to Amateur use. 


Balanced made has two outstanding features 
that are particularly useful for radio 
Amateurs. 


every station has the same privi- 
leges. This is necessary in a "controlled 
anarchy" environment such as Amateur ra- 
dio. Any station can initiate a connection 
(QSO) and any connected station can 
initiate a disconnect. 


Firse, 


Second, by not requiring any master sta- 
tion, the system is very robust. Failure 
of any particular node does not cause the 
network to fail. 


Amateur Needs 


Amateur radio has some specific needs, 
however, that are not addressed by X.25. 
One of these needs relates to the address 
field: AX.25 provides a useful solution by 
encoding the Amateur call sign in the 
address field of the header and allowing 
up tol6 stations per Amateur call via the 
Secondary Station ID (SSID) portion of the 
address. 


Another need is related to the geographic 
area that a "local area" network may have 
to encompass. What happens if your station 
is behind ahillandyou cannot access the 
local Packet bulletin board system? 

AX.25 provides for a "digipeater." This is 
an intermediate station that can be speci- 
fied by the initiator of a connection to 
act as a relay between the two end sta- 
tions. While this application violates 
"oure” bevel. two: protocol, it Satisiies. a 
real need. 


When TAPR was implementing AX.25 for the 
first time, the software team (Margaret 
Morrison, KV7D, David Henderson, KD4NL, 
and Harold Price, NK6K) saw a need for 
multiple digipeaters. Since AX.25 didn't 
allow for this, they decided upon an AX.25 
compatible scheme. 


Basically, three digipeaters were allowed 
to be specified in the "VIA" argument in a 
connect request. Each station that re- 
ceived the packet scanned the digipeat 
field and looked for the first "I haven't 
been digipeated yet" bit that wasn't tog- 
gled to the "I just digipeated this frame" 
state. It then toggled the bit and trans- 


mitted the resultant packet. The end re- 
cipient simply reversed the order of the 
digipeater list, cleared the digipeated 
bits and sent the reply. 


Since digipeating allows for end-to-end 
ACKs only, the NAK being implicit, some 
mechanism had to be found to give digi-~ 
peated traffic priority in a net. This was 
solved via the DWAIT parameter. Essential- 
ly, every packet transmission that is not 
a digipeated packet waits the usual random 
backoff time, but always waits a minimum 
of DWAIT * 40 mSec. Digipeated packets do 
not wait this delay; they have priority on 
the channel. 


This feature wasS found to be very useful 
in such areas as Los Angeles-San Diego and 
the greater St. Louis area. 


When the TAPR kit TNC was developed, a new 
software release was simultaneously re- 
leased. The Version 3 software allows up 
to eight digipeaters to be specified, and 
also allows the use of digipeaters in the 
beacon and unconnected modes of operation. 


Since this extension is a violation of the 
AX.25 protocol as adopted at the AMSAT 
meeting, the TAPR implementation allows 
for totally compatible operation as long 
as not more than one digipeater is speci- 
fied by the user. It is hoped that other 
packet groups will recognize the benefits 
of allowing multiple digipeaters, and at 
such time aS an AX.25 Level Two protocol 
review meeting is held with participation 
by interested Packet groups, TAPR will 
formally propose that these extensions be 
incorporated in the protocol. 


While on the subject of implemented exten- 
sions to AX.25 Level Two, TAPR has exten- 
ded the use of the Disconnected Mode (DM) 
frame. 


AX.25 specifies that this frame will be 
sent only when the addressed station is in 
the disconnected mode and receives a frame 
other than a connect request (SABM). 


The TAPR TNC has a command thatallowsthe 
operator of the station to set a CONnect 
OK (CONOK) flag to OFF, thus inhibiting 
his TNC from being connected to. This 
allows the operator to listen on the chan- 
nel without having to "talk" to anyone. 
Under these conditions, a SABM frame will 
be responded to with a DM frame. 


The other non-standard sending of a DM 
frame occurs when the destination TNC is 
already connected to another station. 


The station requesting the connection, if 
in CONVERSation mode (not TRANSparent 
mode), will get a message stating 


*kk €call> busy 


when a DM frame is received. Likewise, the 
station sending the DM frame will display 


**k Connect request from <call> 


to alert him that a(nother) station wishes 
CO: COnnects 


OTHER EXTENSION 


There are two other cases that arise in 
common Amateur practice that the author 
believes should be addressed at "Level 
Two" in Amateur Packet radio. 


The first is the case of multiple simul- 
taneous connections. This occurs when more 
than one station desires to use the ser- 
vices of another station. 


A “sort of" case of this occurs when one 
station is in a good location and becomes 
a digipeater used by other stations in the 
local area. While no connection exists to 
a digipeater (only through it), the sta- 
tion so used is an illustrative example of 
of multiple connections. 


One of Packet's widely touted benefits is 
its time domain multiplexing (TDM) ona 
given channel. This allows multiple QSOs 
to take place, increasing channel utiliza- 
tion. However, when a Packet station con- 
nects to the local Packet bulletin board, 
it becomes apparent that the bulletin 
board is being underutilized. Other sta- 
tion must wait in line for the first sta- 
tion to disconnect before the next one can 
connect. Meanwhile, the BBS is often stan- 
ding idly by while the connected user 
browses through his mail or digests some- 
thing just read. 


If multiple connections were allowed, many 
users could potentially access the BBS at 
the same (apparent) time. 


Please note that this is a question of 
implementation of AX.25 Level Two -- no- 
thing in the protocol prohibits multiple 
connections. The upcoming Version 4 soft- 
ware release for the TAPR TNC will allow 
such multiple connections. 


One major difference between Amateur oper- 
ation and commercial practice is in the 
use of roundtables. This is a mode of 
operation where there are several stations 
that are engaged in a multi-way conversa- 
tion. 


Such operation is very useful when one 
wants inputs from a number of others on a 
particular subject, or when a traffic net 
has items of general interest (a swap net 
comes to mind as a typical example). 


AX.25 Level Two does not allow for this 
mode of connection. While the next lay- 
er(s) of protocol will undoubtedly allow 
some semblance of this kind of operation, 
it will probably be dependent on some sort 
of "master@' linking station. This may 
reduce the robustness of the local system, 
which could be especially critical in 
times of local emergency traffic handling. 
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It is the author's belief that such oper- 
ation is totally feasible within the Level 
Two environment by simply making use of 
the two "reserved" bits in the seventh 
octetofeachcall in the address field. 


While this is not a formal proposal, the 
idea is as follows. 


[1] The use of up to ten call signs is 
permitted in the address field (in the 
Same manner as implemented in the TAPR- 
extended digipeater string). This allows 
up to nine destination stations in the 
multi-way connection. 


[2] If the two bits marked "RR" in the 
seventh octet of the call are set to a 
"ii", the call is treated like a digipea- 
ter -- this allows digipeaters in the case 
of certain stations in the multi-way con- 
nect, but reduces the number of destina- 
tion stations by the number of digipeaters 
specified. 


[3] If the 6th bit (counting from 0) in 
the seventh octet is a "@", such that the 
field marked "RR" is "198", the station is 
treated as a destination station in the 
multi-way connect. Such a station would 
scan the previous addresses to see if this 
framewastohavebeen sent via adigipea- 
ter, and if so, if it in fact has been 
digipeated. The station would then con- 
tinue the scan to see if it was requested 
as a digipeater for some other destination 
station in the multi-way connect. 


[4] If the station is a destination sta- 
tion, it would read the control byte and 
act. “accordingly. 


This mechanism allows a single packet 
transmission to be explicitly sent to 
multiple destinations, avoiding the inef- 
ficiencies that would result from a chan- 
nel bandwidth utilization standpoint if 
the sending station had to use the multi- 
ple connection approach and send a packet 
to each destination individually. 


The nextproblemto solveisthemanner in 
which ACKs are handled. 


Each destination station would only have 


to send an ACK to the station originating 
the packet in question. Thus, a non-multi- 
way packet would be sent, the digipeat 
field being assembled by reading the ad- 
dress list backwards from this destination 
station to the first encountered non- 
digipeater. 


A variation of the TAPR TNC DWAIT parame- 
ter would be used, wherein the station 
initiating the ACK would hold off for some 
number of milliseconds times his position 
in the address field. This would avoid 
collisions in most cases, while stream- 
lining the ACK process -- a sort of slot- 
ted ACK. 


To clarify the above, assume a station 
sent the following address field (an * 
indicates a digipeater, a # indicates a 
destination station): 


WA7GXD |N@ADI *|N7CL #|/NKGK #|/N@OADI # 


In this case, WA7GXD is sending a packet 
to N7CL via NOADI, to NK6K directly and to 
N@ADI directly. 


N7CL would ACK via N@OADI; NK6K and N@ADI 
would ACK directly, with N7CL sending the 
first ACK, followed closely by NK6K and 
N@ADI. 


If WA7GXD did not correctly receive the 
ACK from NK6K, the packet transmission 
would be repeated, but either (a) would 
only be sent to NK6K (Non-ACKers only) or 
(b) would be sent to all stations again, 
but the already-ACKed stations would ig- 
nore the packet because the N(R) and/or 
N(S) counters would not have been updated 
by WA7GXD. 


This informal proposal is not being pre- 
sented with the idea that it is the best 
solution to a multi-way connection at 
Level Two: rather it 1S suggested as a 
possible, compatible means of achieving 
this end. 


CONCLUSION 


AX.25 Level Two has been proven as a work- 
able protocol in the Amateur Packet radio 
environment. With suitable extensions, 
based on field feedback from active Packet 
users, it can be made even more suitable 
for long term usage. 


Some extensions have been implemented and 
tested in the field for an extended period 
of time: these extensions have been out- 
lined. 


The need for as-yet unimplemented exten- 
Sions to allow multiple and multi-way 
connections has been pointed out anda 
possible approach for multi-way connec-— 
tions suggested. 
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ABSTRACT 


UoSAT/OSCAR-11 contains a digital store- 
and-forward communications facility. This 
paper presents some background on the 
development and implementation of this 
experiment as well as describing its de- 
sign. 
BACKGROUND: PACSAT 

The Radio Amateur Satellite Corporation 
(AMSAT), in conjunction with Volunteers in 
Technical Assistance (VITA), is currently 
developing a Packet radio "flying mail- 
box", dubbed PACSAT (for PACket SATel- 
lite). This satellite is projected to 
contain two identical digital store-and- 
forward communications facilities, each 
containing 2-megabytes of storage capacity 
with multiple uplink channels in the 435- 
438 MHz satellite sub-band and downlinks 
in the 2-meter satellite sub-band. 


During a design review conference held in 
Boston during the weekend of 28 July 1983, 
representatives from the University of 
Surrey (creators of UoSAT/OSCAR-9) indi- 
cated a potential launch opportunity for 
an Amateur satellite with the LANDSAT D' 
mission, scheduled for February, 1984. 
While this launch was far too soon for 
PACSAT, which will incorporate many new 
design concepts, it was viewed as a candi- 
date for flying a communications experi- 
ment based on some of the new technology 
expected to be applied in PACSAT. 


The opportunity not being officially con- 
firmed by NASA, and the development sche- 
dule being brief to the point of absurdi- 
ty, no public announcement was made of the 
possibility of an early 1984 Amateur digi- 
tal communications satellite after the 
meeting. 


UoSAT/OSCAR-1l: THE OPPORTUNITIES 


The team at the University of Surrey, 
under the direction of Dr. Martin Sweet- 
ing, saw the potential launch of UoSAT-B 
as a chance to further their experiments 
on gravity gradient stabilization, thwar- 
ted by a recalcitrant boom on UoSAT/OSCAR- 
9, as well as provide another opportunity 
to explore the near-earth region of space 
with various radiation detectors, particle 
detectors and the like. It would also 
afford an opportunity to gain further 
experience with satellite construction. 
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The PACSAT digital design groups viewed 
the launch opportunity as a chance to 
prove certain concepts envisaged for PAC= 
SAT, as well as a chance for "calibration" 
in satellite design. The satellite would 
provide a proving ground for protocol 
development and experimentation for the 
PACSAT mission. In addition, it would give 
some members of the design team a chance 
for early hands-on satellite experience 
prior to the actual launch of PACSAT in 
1986. Finally, some members of the team 
saw UoSAT-B as an opportunity to try new 
battery management techniques in an effort 


to lengthen the service life of "Phase 
Two" (low orbit, long-life) Amateur satel- 
lites. 


VITA viewed the opportunity as a way to 
establish "proof of concept" by actual 
field trials during the more ambitious 
PACSAT design phase. 


DIFFERENCES IN OSCAR-11 AND PACSAT 


PACSAT will use advanced modulation and 
access techniques to maximize reliability 
and minimize bandwidth requirements. It 
will have four uplink channels per Packet 
experiment and one downlink; there will be 
two complete experiments on board. Each 
channel is expected to support a data rate 
of 9600 bits-per-second (bps). Each exper- 
iment will contain 2-megabytes of data 
storage memory. There will be multiple 
microprocessors in each experiment. HDLC 
will be used; an extended AX.25 style 
protocol will be implemented and the 
satellite will be generally available to 
all Amateurs. 


OSCAR-11, on the other hand, contains only 
a single digital communications experiment 
(DCE). It has 126-k of total RAM capacity, 
16-k of which is error-detecting-and- 
correcting (EDAC) memory for program stor- 
age, system stack and the like. The lim- 
ited uplink and downlink resources mean 
that the DCE must time-share with other 
spacecraft use of the beacons. OSCAR-11 is 
a general research satellite: the DCE is a 
secondary experiment, not the primary one. 
Modulation is simple AFSK of an F3 signal: 
the data rate is limited to 1200 baud. The 
data encoding technique uses simple UART- 
compatible asynchronous characters instead 
of the more complex (and more efficient) 
HDLC formats in common Amateur Packet use. 


Further, the DCE is a proof-of-concept 
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experiment to prove (or disprove) the 
viability of certain recent technological 
advances for use in low earth orbit in a 
limited radiation environment. Hence, much 
of the task of the system is to exercise 
and report on the state of the memory 
devices, current consumption, changes in 
operational behavior and the like. 


Nonetheless, OSCAR-11, through the DCE 
facility, provides aA unique opportunity 
for developing non-real-time gateway oper- 
ations for Packet radio use. Such gateway 
activity, while limited to only a relative 
few stations with direct access to the 
satellite, will provide the opportunity 
for a relatively large number of users to 
participate in the usage of OSCAR-11 by 
sending traffic through the gateway sta- 
tion S 


The remainder of this paper will focus on 
the design and implementation of the Data 
Communications Experiment, or . DCE, euir= 
rently flying on UoSAT/OSCAR-11. 


DCE: DESIGN OVERVIEW 


The PACSAT project design team is spread 
across the North American continent. The 
PACSAT groups involved in the DCE are: 


APU/CCU (Applications Processor Unit/Chan- 
nel Communications Unit) = based in Tuc- 
son, Arizona. This team is responsible for 


the computing hardware design for the 


various PACSAT microprocessors. 


Ground Station = based in Dallas, Texas. 
This group is responsible for the PACSAT 
ground station design (not to be confused 
with the satellite command stations). 


RAMUNIT (Mass Storage) = based in Ottawa, 
Ontario. This group is responsible for the 
2-megabyte mass storage subsystem design 
to be used in PACSAT. 


SOFTWARE = based in Los Angeles, Califor- 
nia. This group iS responsible for all 
software that will run in the processors 
designed by the APU/CCU group. 


Unlike previous AMSAT satellites, PACSAT 
will depend on the use of high-speed mi- 
croprocessors. The most sophisticated Ama- 
teur satellite to date, AMSAT/OSCAR-1QG, 
uses the RCA 18%92-series COSMAC micropro- 
cessor. This device, while available in a 
radiation tolerant form, is not fast. How- 
ever, it will run on 198-volts and is more 
than adequate for the task of managing the 
spacecraft's resources. PACSAT must rely 
on processing power to perform its mission 
as well as manage the various spacecraft 
Support systems: the 2802 -samply -isn"t 
powerful enough. In fact, no single micro- 
processor available in CMOS is powerful 


enough -- PACSAT will use three micropro- 
cessors per Packet experiment, or Six 
total. The spacecraft itself may require 


the use of yet another! 


The microprocessor chosen for PACSAT is 
the National Semiconductor NSC-800. This 
is a z-80 work alike device, able to draw 
On the vast resources of proven Z-80 soft- 
ware design tools. Capable of executing 
instructions at a rapid rate when operated 
with a 4 MHz clock, studies by the soft- 
ware design group determined that this 
processor would be capable of performing 
the necessary tasks associated with data 
collection and management projecte4q for 
the PACSAT mission, 


However, AMSAT has no flight experience 
with the NSC-898, nor with any low-thres- 
hold CMOS devices. Thus, the NSC~869g was 
selected to fly on the DCE in order to 
evaluate the high-speed, low-threshold 
CMOS technology of which it is fabricated 
in the low-earth orbit environment. 


The DCE's NSC-800 is buffered, and its 
address/data bus demultiplexed, via 5-volt 
high-speed CMOS (HCMOS ) devices of the 
54HCXXX family. 


This, too, represents a departure from the 


relatively "safe" high-threshold silicon- 
gate technology traditionally flown in 
Space applications. The nature of radia- 


tion damage to MOS semiconductors is such 
that the switching threshold voltage tends 
to rise- This is due to trapped charges in 
the gate oxides that occur when bombarded 
by particles with the right energy levels. 
A high-threshold device, operating at 194- 
volts, has more "headroom" in which to 
sustain damage before its input switching 
thresholds approach the Vdd level (10- 
volts). In the case of PACSAT, and the 
DCE, higher-speed operation is of para- 
mount importance -- standard CMOS devices 
Simply won't do the job needed. Thus, a 
higher-risk technology is employed to 
allow the task to be accomplished at all. 
The DCE provides a mechanism to evaluate 
this risk in a real space environment. 


The primary DCE memory is comnosed of CMOS 
static RAM. There is a 16-k byte block of 
memory that includes a Hamming code EDAC 
section. This memory is built around Har- 
ris 6564 ICs, a hybrid utilizing 4k by 1 
CMOS static RAMs. The E'DAC support logic 
is fabricated entirely of HCMOS davices. 
An error counter is mapped into the NSC- 
800 I/O space to allow the processor to 
determine the number of errors corrected, 


The Integrated Housekeeping Unit (IHU) -- 
the microcomputer that manages the opera- 
tion of OSCAR-11 -- is designed around the 
1802 and has an EDAC memory built around 
4116 DRAMs and traditional 4000  £4series 
CMOS logic. This unit also has an error 
counter, and one of the most important 
areas of measurement associated with the 
technology evaluation is the comparison of 
the two error counters. This information, 
coupled with the absolute levels of radia- 
tion as measured by other detectors on 
board the spacecraft, will help determine 
the Suitability of CMOS static RAMs for 
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future satellite packages, including PAC=- 


SAT. 


The limited knowledge available (at least, 
in non-classified form), indicates that 
DRAM is best for overall power consumption 
over the projected life of the satellite 
-mission, while CMOS is better initially. 
UoSAT/OSCAR-11 will give us valuable data 
as to the relative performance of these 


technologies in the particular environment 
of low earth orbits. If the degradation in 
performance (as measured by changes in 


nominal current consumptions when the cpu 
is performing well-known tasks) is accep- 
table, CMOS static RAM may offer the op- 
portunity to reduce power consumption, a 
major consideration in spacecraft systems 
design. The radiation experiments, along 
with relative errors-corrected data, may 
show which technology is more tolerant of 
the particular low earth orbit environment 
which OSCAR-11 (and later, PACSAT) inha- 
bigs: 


Additional RAM is provided in the form of 
2k-by-8 "bytewide" CMOS static RAMs. A 
total of 14k-bytes of Harris military 
grade 6516 components are used. While 
there is no hardware EDAC circuitry used, 
this memory will be used to determine the 
susceptibility of this technology to radi- 
ation induced errors -- again, the EDAC 
memory counter will provide invaluable 
data for comparison purposes. 


EDAC circuitry 1S not really useful for 
bytewide components a grazing particle 
may upset the data in several cells, and 
this could mean that many bits of a par- 
ticular byte are corrupted, making a very- 
wide word memory necessary to detect, much 
less correct, such errors. Instead, it is 
envisaged that a software encoding scheme 
could be implemented to correct these 
errors, Similar to the "fire codes" used 
to recover from error bursts when reading 
from a Winchester disk, for example. Error 
detection will be fairly simple in some 
experiments when a predictable pattern is 
written to memory and later read back for 
comparison. 


The PACSAT mass storage mechanism current-— 
ly being explored is that of arranqing a 


large amount of high-speed static CMOS RAM 
in a bank-switched scheme in the upper 
address space of the NSC-8@@. High density 
(8k-bytes per chip), low-threshold CMOS 
devices were selected for a portion of 
this memory in the DCE (Hitachi HN6264LP- 
12s), with lower density RAMs serving to 
implement other banks (Hitachi military- 
style 6116s). Bank selection and bus iso- 
lation is via 5-volt HCMOS logic of the 
54HCXXX family. 


Bootstrapping the processor from a cold 
Start uses a scheme with bank selected 
CMOS fusible link PROMs. EPROMs are unuse- 
able due to their dependence on trapped 
charges for memory retention. The PROM 
technology selected has been used in space 


3.66 


before, although little data is officially 
available on their performance. 


To help ensure reliability, a pair of 


PROMs, bank selectable by the spacecraft 
command decoder, are incorporated in the 
DCE. 


The use of PROM in space is another first 
for the DCE for AMSAT applications, at 
least as far as bootstrap memory iS con- 
cerned. The 1802 has a special mode of 
operation that allows boostrapping code 
directly into RAM without any ROM whatso- 
everl The NSC-800, on the other hand, does 
not easily lend itself to such usage (al- 
though the Japanese JAS-1 Amateur satel- 
lite, scheduled for an early 1986 launch, 
uses a ROMless NSC-800). This meant that a 
thoroughly tested, absolutely buqfree 
bootstrap loader had to be designed, tes- 
ted and burned into the PROM prior to 
construction of the flight DCE! While 
developing such a program may appear sim- 
ple at first glance, the task is not tri- 
vial. The system must be errorless in its 
loading, function without any RAM whatso- 
ever for the loader (no absolute memory 
location can be considered safe from fail- 
ure in space applications) and must work 
well in a very noisy (error-prone) envi- 
ronment. This task was accomplished by the 
RAMUNIT group, with assistance from the 
Software team. 


Serial I/O is handled by a pair of 6402 
UARTsS. These devices were successfully 
flown in UoSAT/OSCAR-9 and they are compa- 
tible with the NSC-800. There are two 
UARTs and they are multiplexed to enable 
communication with any receiver, transmit-— 
ter or serial data stream in the space- 
craft (the IHU, for example). Serial I/0 
may be operated in an interrupt-driven or 
a polling fashion. 


Parallel I/O is handled by a Harris 
82C55A. It is allowed to control the ser- 
ial port multiplexers, read data from the 
navigation magnetometer, select the UART 
data rate clocks, determine the cpu clock 
rate and select the RAMUNIT active bank. 


A tap in the clock oscillator/divider is 
coupled to an interrupt line to allow the 
NSC-800 to keep track of elapsed time for 
various internal experiments. 


Finally, level-shifters are provided to 
interface the DCE with the rest of the 
spacecraft. Command control is asserted 
over the DCE reset line, bootstrap PROM 
select, cpu clock rate (0.9 or 1.8 MHz) 
and DCE power on/off. Telemetry status 
points indicate the state of all the com- 
mand lines to the DCE, while telemetry 
channels provide measurement of current to 
the RAMUNIT, the CPU and the EDAC memory 
subsystems. 


DCE: DESIGN HISTORY 


With the limited time available to imple- 
ment the DCE, many decisions had to be 


made rapidly and implemented in no less 
timely a fashionl 


Investigations were made into memory tech- 
nologies, component availability and EDAC 
memory design by the APU/CCU group during 
the month of August. Meetings were held 
with various AMSAT engineering people and 
vital information obtained. 


The wire-wrap prototype of the NSC-800 
based cpu and memory systems was accomp- 
lished during the Tucson floods of Septem- 
bers: -1963'. 


By October, the Ground Station group was 
busily preparing to lay out the PC boards 
for the CPU and GMEM (General MEMory) 
cards. The wire wrap prototypes were made 
functional in Dallas and the layout work 
began in earnest. 


By the first part of December the artwork 
was delivered to Tucson and the actual 
flight PC boards fabricated. These were 
hand carried to Dallas where the engineer- 
ing prototypes were constructed. The re- 
maining boards and parts were then sent by 
air to Ottawa where the actual construc-— 
tion of the flight units was to take 
place. 


Meanwhile, the NiCd cells were procured 
and sent to Ottawa in October for evalua- 
tion, classification, and integration into 
the spacecraft's battery. The cells were 
then shipped on to Surrey. The RAMUNIT 
design was completed and the PC boards 
laid out and fabricated in Canada. 


The group leader in Ottawa was severely 
burned in a fire about this time: although 
his recovery was very painful, he doggedly 
persisted on the project. 


Software for the DCE was developed in 
Ottawa and Los Angeles, with the final 
burning into PROM carefully controlled by 
the Ottawa group. 


In early January, the flight boards were 
constructed and integrated into the flight 
module (three circuit boards crammed into 
a container only 31 mm thick!) in Ottawa, 
with full-time participation by the PACSAT 
project leader. 


The flight unit was hand carried from 
Canada to Surrey, where it was further 
tested and integrated into the spacecraft. 
The final hardware bugs were exterminated 
with coordinated efforts from both sides 
of the Atlantic. 


The flight DCE arrived in the States in 
mid-February as part of UoSAT-B. Magqneto- 
meter calibration was accomplished at 
Goddard Space Flight Center, and the sa- 
tellite and support team then travelled to 
Vandenberg Air Force Base, on the Califor- 
nia coast. There, it was met by members of 
the DCE team, and several days were spent 
verifying the overall health of the DCE 
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and the spacecraft in general. All passed 
Wit ““tivying”. <colors.2.4 


OSCAR-11: A STATUS REPORT 


UoSAT-B became UoSAT-2/OSCAR=11 on 1 March 
1984 after a textbook launch on a Delta 
vehicle. Initial telemetry was positive. 


On March 2nd, however, an anomaly occurred 
with the 145.825 MHz beacon transmitter. 
As of this writing (18 March 1984), the 
spacecraft is silent, its command receiver 
at 78-cm apparently being blocked by the 
ailing 2-meter beacon. Teams at Surrey and 
Los Angeles are actively trying to unravel 
the puzzle and get the satellite ina 
functioning mode. With persistence and a 
little luck, 1984 should herald the acti- 
vation and use of the first major digital 
store-and-forward Amateur communication 
facility in space: this should put empha- 
Sis on the development of a workable gate- 
way plan. 


DCE : THE PLAYERS 


The author wishes to recognize the many 
volunteers who made the DCE possible. Any 
omission is purely unintentional. 


DCE Project Leader : Harold Price, NK6GK 
Ottawa Team List (Battery and DCE) 
UoS-B Battery Development Team 

D. (Dick) Atkinson - VE3JBO 

B. (Bob) Gillies ~ VE3JA 
wy 
S 


(Stan) Kazmiruk =- VE3JBA 
. (Gord) Scale - Non Amateur 


Qn DD 


DCE Software 
H. J. (Hugh) Pett - VE3FLL 


DCE RAMUNIT and Construction 


Ri -H (Ron) Archer = VE3CNM 
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Abstract 


This paper describes a new datalink protocol 
which is being developed by the author in Vancouver 
and being tested in Toronto. It is designed to 
replace the previous link level protocol commonly 
known as the 'Vancouver protocol' and it addresses 
all the major limitations of that protocol. 


Historical Background 


In the summer of 1979 in Vancouver I had a 
protocol in operation in the VADCG TNC which is not 
well known. It was a protocol designed to talk to a 
"Station Node' or central controller which 
dynamically assigned addresses to each TNC which 
connected to it. All TNCs communicated to each 
other through the connection services provided by 
this station node. The channel was shared using 
carrier sense multiple access (CSMA) techniques 
Similar to most Amateur acket operation today. 
Although this system worked quite well and in many 
respects was more advanced than anything currently 
in use today we had two major problems which have 
resulted in it not being used today. 


Firstly, the station node used the facilities 
of my S100 CP/M system which was being used to 
develop both the station node and TNC programs. The 
VADCG did not have the funds or equipment to 
dedicate to the station node and I was not ready to 
donate my only computer to the cause. The group 
tried to assemble equipment which could be dedicated 
to the station node but were unsuccessful mainly due 
to funding problems. 


Secondly, in the fall of 1979, I was asked by a 
group in Hamilton, Ontario to write a protocol for 
them which would allow communication directly from 
one TNC to another without the need of a station 
node intermediary. This request was made so that 
they could use and test the TNCs before they 
assembled the funds to build their own station node 
and then switch over to the Station node based 
software. They had a similar problem to that of the 
Vancouver group = lack of fundse 


And so, by request, I modified the protocol 
used to communicate to the station node by 
eliminating the dynamic address assignment system 
and substituting a fixed address system and made a 
minimal amount of changes required to provide the 
requested facilities. Well, as things turned out 
this 'temporary' protocol became nown as the 
"'Vancouver' protocol and became the _ 'standard' in 
North America for a few years. Te ws. Sta dl a 
standard in common use in many areas today. We 
never have gotten back to the older station node 
software although it is still in our plans to do SO. 


When I wrote it, I never _ intended the program 
to become a standard for packet radio 
communications, only for testing TNCs = which it 
certainly did. It received widespread distribution 
mainly because it was the only thing available and 
also because it was capable of cod much more than 
just test TNCs. In spite of its limitations, it 
still meets the needs of most users at the present 
time. This article 2s written to address: those 
limitations by im Pouene ang a new link level 
protocol which I believe can be used as a base on 
which to build network and transport level 
protocols. 


A meeting of U.S. (only) packet radio grou 
was held in October, 1982 which resulted in t 
adoption of a protocol commonly known as. ‘AX=25' b 
most U.S. packet gece groups. (I would have Liked 
an invitation.) X-25 addresses most of the 
limitations of the eee protocol but is nota 


VE7APU 
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true tink. level. ‘protocol: since it. concerns itself 
with several network level functions as well. It is 
also undergoing changes at the present time and has 
its own set of problems and limitations. It is my 
preference to have a protocol which makes a clear 
separation of link level and network level functions 
as per the ISO model. As far as standardisation is 
concerned, when signals with other protocols arrive 
in the area we hope to be able to provide a gateway 
interface to handle them. 


For purposes of discussion I will refer to the 
orginal Vancouver protocol as the "Vancouver 
protocol' and the new protocol as 'Vancouver Version 
2 protocol’ or ‘'W=2" for short. 


INTRODUCTION TO V-2 


The V-2 
datalink leve 


rotocol is intended to be an efficient 
protocol specifically for the Amateur 
Radio environment but potentially usable in other 
environments as well. Both full and half-duplex 
modes are defined. After link establishment, V-2 
has only 5 octets of overhead per frame in addition 
to the standard 3 or 4 octets required for framing. 
It is strictly a datalink protocol and does not 
provide any network level functions. The network 
level protocol will be provided in a Network header 
which appears only in Information-transfer frames. 


All control information for the link and only 
control information for the link is carried in a 
Link Header and Link Trailer which appear at the 
beginning and end of every frame respectively. Onl 
the information not in the link control fields nee 
be passed to. higher levels of protocol. This 
separation of both function and headers allows 
software for layers to be developed in modular form 
and permits modification of the code for one layer 
to have minimal affect on other layers. 


This protocol makes no. claim or intent. -at 
comparison or simulation of the CCITT xX-25 standard 
although it is the author's opinion that V-2 can be 
compared in the same way as AX-25 can to X-25 with 
as much similarity or more. 


Frame Structure 


All transmissions are sent in frames similar to 
IBM's SDLC and the CCITT's HDLC as well as to AX-25 
and the older Vancouver protocol. The frames are 
encoded in (and decoded from) NRZI (Non Return to 
Zero Inverted) mode by the HDLC protocol controller 
ea The general field format of a V-2 frame is as 
follows: 


Field Descriptions 


This 
synchronisation. 


field is used LOL 
It is either 16 bits of 
sufficient flags for the receiving 
establish bit synchronisation. This field is 
basically .inder” ¢control..of the. HDLC protocol 
controller chip and is transparent to the software. 


preframe 
zeroes or 
Side to 


Flag fields 


All frames begin and end with a flag which is 
the bit sequence 01111110. When sending multiple 
frames one after the other, the trailing flag of one 
frame may be used as the leading flag of the next 
frame. The HDLC protocol controller chip uses a bit 


stuffing and deleting technique to ensure that a 
flag sequence can only appear at the beginning and 
end of a frame. Flags are automatically inserted by 
the HDLC protocol controller chip on transmit and 
are likewise automatically deleted from the data 
stream before passing to the software. i.e. the 
flags are transparent to the software. 


gddress field 


This is a four byte address used to identify 
the link. The old protocol used a one byte address. 
How it is formed is discussed later. This field is 
generated and checked by software. 


Control field 


This is a one byte field. Tt: 2s- used: /t6 
identify the type of frame and provides information 
for supervision of the flow of data over the link. 
This field is generated and processed by software. 
The format of this byte is discussed later. 


Information field 


This variable length field is only present in 
certain types of frames. It must be an integral 
number of octets. Although the hardware allows a 
maximum length of over 65,000 bytes, it is 
recommended that a maximum length of only 200 bytes 
or less should ever be created for transmission. On 
the other hand, the system should be capable of 
handling frames of longer lengths say up to 250 
bytes when received from other nodes. This allows 
room for higher level overhead should it be 
necessary. If unusually long frames are to be sent, 
higher level protocols should agree on the size in 
advance. 


FCS (Frame Check Sequence) 


This is a two byte field generated as per ISO 
standard 3309. This field is automatically 
generated, checked and removed by the HDLC protocol 
controller chip so I will not discuss it’ further. 
It is used to verify the accuracy of the rest of the 
data in the frame. 


Frame Types 


There are three types of frame formats: 
unnumbered, supervisory, or information transfer 
format. The frame type is indicated by the value of 


the low order bit or bits in the control field as 
seen in storage. (Note that this article refers to 
the fields as they are seen in storage = not as how 
they are transmitted by the protocol controller 
chip) If the low order bit (bit 0) is 0 then it is 
an information transfer frame. If both bit O and 
bit 1 are 1 then it is an unnumbered frame. 
Finally; 2f bit 0 16:4-and bit las 0 then 2t 2¢6- a 
supervisory frame. 


Unnumbered-format frames (U-frames) are used 
during link establishment and termination. They are 
also used to transfer data when the data is not to 
be checked aS to its location in a sequence of 
frames. There are a possible 32 types of U-frames 
but only three of these are used in this protocol. 


Supervisory-—format frames (S-frames) are used 
to assist in the transfer of information in that 
they are used to confirm preceding frames carrying 
information. The frames of' the supervisory format 
do not carry information themselves. These frames 
carry an Nr count which is used to confirm received 
frames. They also convey ready or busy conditions 
which assist in coordinating flow control across the 
link and they are also used to report frame 
numbering errors (indicating that a numbered 
information frame was received out of its proper 
sequence). There are a possibility of 4 types of S= 
frames but only 3 are defined in this protocol. 


Information-transfer format frames (I-frames) 
actually transfer the data from higher protocol 
levels across the link. The control field contains 
send and receive counts (Ns and Nr), which are used 
to ensure that these frames are received in their 
proper order (Ns) and to confirm accepted 
information frames (Nr)e The Ns count indicates the 
number of the information frame within the sequence 
of information frames transmitted. The Nr count 
transmitted in a frame is the number (Ns) of the 
information frame that the node transmitting the Nr 
expects to receive next. 
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Frame numbering 
(e 


A node transmitting numbered I-frames counts 
each such frame and sends the count with the frame. 
This count is a sequence number known as NS. This 
sequence number is checked by the receiver's 
datalink layer for missing or duplicated frames. 


A node receiving I-frames accepts each numbered 
frame that it receives (that is error-free and in~ 
its receive count for each 


sequence) and advances 
such frame. The receiver count is called Nr. If 
the received frame is error-free, a receiving 


station's Nr count is the same as the NS count that 
it will receive in the next numbered information 
frame; that is, a count of one greater than the NS 
count of the last frame received. The receiver 
confirms accepted numbered I-frames by returning its 
Nr count to the transmitting node. 


The Nr count at the receiving station advances 
when a frame is checked and found to be error-free 
and in sequence: Nr then becomes the count of the 
"next-expected" frame and should agree with the next 
imcoming Ns -count. If the incoming Ns does not 
agree with Nr, the frame is out of sequence and Nr 
does not advance. Out-of-sequence frames are not 
accepted. The receiver does, however, accept the 


incoming Nr count (for confirmation purposes) if the 
out-of-—sequence frame is otherwise error free. 
The counting capacity for Nr and Ns is 8, using 


the digits O through 7. These counts wrap around; 
that is, 7 is sequentially followed by 0. up to 
seven unconfirmed, numbered information frames may 
be outstanding (transmitted but not confirmed) at 
the transmitter. All unconfirmed frames must be 
retained by the transmitter, because it may be 
necessary to retransmit some or all of them if 
transmission errors or buffering constraints occur. 
The reported Nr count is the number of the next 


frame that the receiver expects to receive, so if, 
at a checkpoint, it is not the same as the 
transmitter's next frame (Ns) number, some of the 


frames already sent must be retransmitted. 


on both ends of the 
during the link 


The Nr and Ns counts 
datal ink are initialized to zero 
establishment phase. 

The Poll bit (P-bit) and receive timeout. 

The Poll bit is bit 4 in the control field. 
It is used to force a response from the receiving 
node when set to J] (on). Whenever a frame is 
transmitted with the P-bit on a receive timeout is 
started by the originating node. This receive 
timeout (T1) is in the order of 1-3 seconds. This 
timeout is cancelled by reception of any frame from 
the other side of the link. If the timeout expires 
before the expected frame is received then the 
transmitting node takes corrective action. The 
number of successive timeouts is counted and reset 
when a frame is successfully received. If the 
number of successive receive timeouts exceeds a 
predetermined level (N1), the next higher level of 
protocol is notified. The higher level may take 
other action such aS terminating the link. 


Note that the receive timeout only proceeds 
when the data link channel is clear. The timeout is 
suspended when the data link channel is occupied. 
On VHF, the datalink channel may be occupied by 
carriers, voice transmissions, QRM, etc. in addition 
to the expected data signals. For this reason, it 
is strongly recommended that CD (Carrier Detect) be 
tested for receive timeouts rather than DCD (Data 
Carrier Detect). All VADCG board installations that 
I know of in Canada are using the squelch line from 
the VHF transceiver rather than the Data Carrier 
Detect line from the modem. Some can select both. 
If the DCD line is used, excessive timeouts will 
occur and it will be difficult or impossible for the 
TNC program to determine proper action. In 
addition, the TNC will transmit on top of other 
stations using the channel which can lead to 
unpleasant verbal exchanges. Remember that no 
Amateur frequencies are exclusively reserved for 
this type of packet activity. 


NODE NAMING AND ADDRESSING 


Before describing link addressing it is 
necessary to understand the network node addressing 
and naming system in which this protocol is designed 
to operate. Also, some terms need to be defined. 
'Node' refers to 


Node = In this article the word, 


any entity in the communications system which 
originates or receives frames. 


Node Names 


Associated with each node in the network is a 
7.character uppercase. string of ASCII. characters. 
The first six characters of Which are the Amateur 
Radio call sign padded by ASCII blanks (20 
Hexadecimal) on the right. The final character is a 
suffix used to discriminate between multiple nodes 
which have the same call sign. This suffix will 
normally be an ASCII blank (20 hexadecimal) and_any 
additional occurrences of the same call sign will be 
identified by the ASCII numbers 1,2,3, etc. Each 
node in the network thus has a unique ‘Call sign. 


For example: 


KA6M*** (The * represents a blank) 
Or if KA6M has another node operating: 
KA6M** 1 


Node Address 


Also waage poe with every node in the network 
is a _ two byte (16-bit) binary address. This address 
can be derived from the node name by use of a 
modified cyclic redundancy (CRC) checking algorithm. 
The algorithm operates on the 7-byte node name 
artery as a binary number and generates a 2 byte 
n ere 


The algorithm does not generate node addresses 
with FF (hexadecimal) in the first byte because 
these are reserved for special broadcast functions. 
Please see Appendix A for details of the algorithm 
and a sample implementation for an Intel 8080 
microprocessor. 


The special destination node address of FFFF 
(Hexadecimal) is used as a general broadcast address 
and destination addresses beginning with FF are 
reserved for selective broadcasts and special 
purposes. 


Link Address 


The: [ink address field ain the frame: 1s four 
bytes long and is generated by concatenating the 2= 
pee node addresses of the nodes at either end of 

e link. Each link actually has two addresses, 
identifying the two directions that data can flow 
accross the link. For example, if A and B represent 
the node addresses of linked nodes then AB and BA 
are the two addresses of the link between the pair. 
Address AB represents the link address for data 
originated by B and destined for A while BA 
represents the ink address for data originated by A 
and destined for B. The destination node address 
always comes first. 


Use of Selective Receive 


This link protocol has been designed to make 
good use of the selective receive function available 
on most HDLC/SDLC protocol controllers such as the 
Intel 8273. The 8273 can be set to pass to the 
software onl frames which have a specific 
combination “of bits in the first byte after the 
leading flag. In this protocol, this byte is the 
first byte of the destination node's address. If a 
node does selective receive only on the first byte 
of its address, it can eliminate 99.6% (on average) 
of the link traffic from having to be read into 
memory buffers and analyzed by software and yet 
still be able to do multiple link establishments, 
terminations, etc. 


There are a number of modes of operation 
possible with this protocol using selective receive 
options as follows: 


lL. weelective .éceive ionly onthe firs. bytevor. the 
node's address for using multiple links as above. 
This would normally be used in anything but the 
unlinked state but would be used in the unlinked 
State: 1f it was not "desired, to-do any of the 
activities in items 2 and 4 below such as a node 
with a CBBS host. 


2. Selective receive only on address 
(Hexadecimal) to monitor broadcast 
transmissions and not establish links. 


FF 
type 
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Selective receive on address FF and also the 
first byte of the node's address. (2 selective 
receive addresses are supported on the 8273) Links 
can be set up and broadcast messages can be 
received. Useful in the unlinked state. 


4. Receive on all addresses. THaes “ais. NOt. a 
selective receive but it is useful for evesdropping 
on transmissions intended for others or monitoring 
activity on the channel to put it more politely. 
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Link States 


Data links are set up and discontinued as 
required by the nodes in the network. They are 
temporary. The normal life history of a datalink 
usually ol through three basic phases or 
states name establishment, information transfer 
and i oaniiacion: Although technically not a link 
state, the situation where a node has no datalinks 
in any of the above phases is called the '‘'unlinked' 
state. 


INFORMATION-TRANSFER FRAMES 


I (Information) frames are numbered. The Ns 
count provides for numbering the frame being sent 
and the Nr provides acknowledgement for the I frames 
received. When duplex information exchange is in 
continual process! each node reports its current Ns 
and/or Nr counts an each I or S frame exchanged. I= 
frames are only originated by nodes that are in the 
information-transfer phase. 


The expected acknowledgement is an S or I 
format frame whose Nr count confirms correctly 
received frames. (S-frames may be interspersed with 
I format frames, as needed.) An I-frame always has 
an I-field, in fact, an I-format frame is considered 
invalid if it does not contain an I-field in this 
protocol. See figure 1 for the layout of the I- 
frame control field. 


Control Field Control Field Bits 
Type 765 4 321 0 


Where: 

Ns is the send sequence number. 

Nr is the receive sequence number. 
P as the Poll. bit. 


I-Frame Control field 


Figure lL. 
I-Field Content 


The contents of the I-field in an I-frame are 
not the concern of the datalink protocol. They are 
determined by higher levels of protocol. The design 
of the V-2 network level has not been completed and 
will be the subject of another per.. However, the 
work on the network leve has progressed 
sufficiently that some advice can be given to 
network level implementors and testers that will 
allow different network headers to be identified and 
to co-exist on the same channel. It. is for this 
purpose that the following Network level information 
is included here. 


The first sub-field in the I-field is called 
the Network Header. It is a variable length field 
composed of an even number of bytes. The low order 
four bits of the first byte indicate the number of 
words (1 word = 2 bytes) long the the Network Header 
ise Fhe high order bit indicates if there is 
another header following the Network Header and the 
three remaining bits are used to identify different 
Wines of Network Headers that may have the same 

ength. 


The bit layout of the first byte in the Network 
Header is as follows: 


16543:2 10 
Be ae ae aly, abe, 20s 


Bitnumber 


F indicates another header follows if 1 

T T indicates the Network Header type 
L L LL indicates the length (in words) 
the Network Header. 


Where: 
of 


Even if only the link level protocol is in use 
the following two-byte dummy Network Header should 
be included as the first subfield in the I-field: 


0100 (Hexadecimal) 


This will indicate that the header is 2 bytes 
long and that no other header follows this one. 


SUPERVISORY FRAMES 


There are three types of supervisory frames 
defined by this protocol: 
RR Receive Ready 
RNR Receive Not Ready 
REJ Reject 


An S (Supervisory) frame must not contain an I= 
Evel. It is considered invalid if it does. See 
figure 2 for the layout of the control field of an 
S-frame. S-frames are only originated by nodes on 
links which are in the information-transfer phase. 


Control Field Control Field Bits 
Type 765 4 3 1 0 
RR 


RNR 
REJ 


2 
0 
1 
0 


Figure 2. S-frame Control field. 


RR (Receive Ready) 


Indicates that the originating node is ready to 
receive I-frames and acknowledges receipt of 
numbered I-frames through Nr-lI. It must be sent to 
clear a previous not ready condition (RNR). It can 
also be sent with the P-bit on to elicit a response 
from the node at the other end of the link. Ie: aS 
sent with the P-bit off in response to a poll by the 
other side when no I-frames can be sent. 


RNR (Receive Not Ready) 


Indicates that the originating node is 
temporarily not ready to receive I-frames and 
acknowledges receipt of numbered I-frames through 
Nr-1. It is usually sent when buffering limitations 
and other internal restraints in the node are 
encountered. It can be sent with the P-bit on to 
elicit a response from the node at the other end of 
the link. It is sent with the P-bit off in response 
to a poll by the other side when no I-frames can be 
sent. This not ready condition must be cleared by 
the sending of an RR or REJ frame. Note that the 
node should still be capable of handling S and U 
frames even in the not ready condition. 


REJ (Reject) 


Acknowledges receipt of numbered I-frames 
through Nr-1l and indicates that the originating node 
is ready to receive I-frames. It requests the 
retransmission of numbered I-frames starting at the 
Nr contained in the REJ frame. Its purpose is to 
speed up recovery of dropped frames when operating 
full duplex. Note that this frame is only used with 
full duplex links and should never be sent on half 
duplex channels. Only nodes intending to operate 
full duplex need incorporate support for this type 
of frame. Lt .2S> Opi Tonal, REJ frames may be 
interspersed in the sequence of transmitted frames 
on full duplex links. The REJ condition is cleared 
when the requested frame has been correctly 
received. 


UNNUMBERED FRAMES 


There are three types of unnumbered format 
frames supported by this protocol: 


XID Exchange station identification 
DISC Disconnect 
UI Unnumbered information (formerly NST) 


Unnumbered frames are not sequence-checked and 
do not use Nr or Ns. See figure 3 for the layout of 
the control field for these frames. Although I am 
using names and control field formats common to 
HDLC/SDLC nomenclature, the actual usage of the 
unnumbered frames in this protocol is different. I 
tried to use the HDLC name with the closest 
approximation to what this protocol is doing. I 
hope this does not cause any confusion. My other 
alternative was to use the undefined HDLC U-frames 
and give them my own names. 


Note that the previously described I and S= 
frame usage adheres fairly closely to the HDLC/SDLC 
standards but there are major divergences in the 
usage of the unnumbered format frames. This 
protocol is not intended to be a copy of any other 


protocol but has been designed pragmatically. When 
a piece of another protocol fits the need, it has 
been used but when the need is unique, then unique 
solutions are designed. This method reduces the 
amount of development effort. It also helps those 
who are familiar with other protocols to quickly 
develop a familiarity with this one. On the other 
hand, there may be some confusion when divergences 
with the other protocols occur. 


XID 
DISC 
UI 


Where: 
P is the Poll bit. 


Figure 3. U-Frame Control field. 


XID (Exchange station Identification) 


The XID frame is only used during the link 
establishment phase of the protocol. I was thinking 
of calling it the 'LINK' frame rather than XID. 
Before I-frames can flow across the lank, 
information is exchanged between both nodes in the 
XID frames. The opposite node's XID information is 
analyzed and a determination is made whether or not 
the link can be established. If both nodes like 
what they see, then the link is established and I 
and S-frames can flow across the link. On the other 
hand, if one node doesn't like what it sees, then it 
sends an XID frame to the other with a reason code 
filled in which indicates what it didn't like and 
the link is not established. XID frames are only 
transmitted on links in the establishment phase. 
The XID frame A, C and I fields are as follows: 


AAAACSSSSSSSDDDDDDDPTR 


Where: 

AAAA is the address field. 

C is the control field (XID). 

SSSSSSS is the transmitting node's 7=byte name. 
DDDDDDD is the destination node's 7=-byte name. 
P is the protocol level field. 

T is the link type field. 

R is the reason field. 


Protocol level field (P-field) 


This is a one byte field in the XID frame 
indicating the version of protocol being used by the 
Originating node. By testing this field, the 
receiving node may determine if it can communicate 
with this type of protocol. At the present time, 
this field is O1 (Hexadecimal), indicating this is 
Level 0 of the protocol. (bit 0 1s: on). This version 
number should be changed whenever a new level is 
produced which has features or changes which are not 
compatible with previous levels. This feature has 
been added in anticipation of future revisions and 
extensions of the protocol. 


The receiving node checks for a match on this 
field. Note that a node may support multiple levels 
of protocol in order to communicate with nodes of 
different levels. For example, a primary station 
which supports multiple protocols may send an XID 
saying that it can communicate with levels 0 and 1 
of this protocol by sending a P-field of 03 
(Hexadecimal) with bits 0O and 1 on. The secondary 
determines if communication is possible by and'ing 
its own version(s) with that in the incoming P= 
field. If the result of this operation is non-zero, 
then the protocol levels are compatible and the 
secondary will respond with a P-field indicating 
which protocol it is using. If the result of this 
operation gives more than one bit on, then the 
secondary can choose which of the protocols it 
wishes to use. 


For example: 


1 Primary sends P-field of O3 indicating it can 
support levels 0O and |. 


2. Secondary logically tands' the primary's P-field 
with its own protocol version number of O1 (Only 
supports level 0). The result is 01 


3, since “Che: result.was non-zero, Che. protocols are 
compatible and the Secondary can respond with a P= 
field value of OL 
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On the other hand, if the result is zero, then 
there is a protocol incompatibility and the 
secondary will respond with the protocol mismatch 
bit (another P-bit) set in the Reason field (R= 
field). The link will not be established. 


Link type field (TI-field) 


The T-field is a one byte field in the XID 
frame indicating the tyes of link being established. 
At present the only choice in link type is either 
full duplex or half duplex. The byte format is as 
follows: 


Bit number 76543210 
XXXXXXXFEF 


Where X indicates reserved bits = must be 0 
F indicates full duplex if 1, half duplex if 0 


This field is checked by the receiving node and 
if it is capable of handling the type of link 
indicated it will respond with a matching indication 
in its. cown T-field. But 1f;, for example, che 
primary requests a full duplex link and the 
secondary only has support for half-duplex, the 
secondary will respond with the Link type mismatch 
bit (T-bit) set in the reason field (R-field). 


Reason field (R-field) 


The reason field is a one-byte field in the XID 
frame used by the secondary to report to the pealely 
the reason why the link is not being established. 
If any bits are on in this field, the l-ink was not 
established. The R-field layout is as follows: 


Bitnumber 10 
XXXXARTP 


Where: 

X = reserved bit = must be 0. 

A - Address duplication (See Restrictions) 

R - Resource limitation 

T = Link type field mismatch (see T-field desc.) 
P = Protocol mismatch (see P-field description.) 


The R-bit being on (1) means that the 
originating node has a temporary resource eran hs 
which prevents the establishment of the link. The 
most likely reason being that it has a limitation on 
the number of simultaneous links that the node can 
Support. Most nodes used in Amateur Radio so far 
can only eupEOr one link at a time, andso, if a 
node has this link already established when it 
receives an XID frame from a third party node, it 
should respond with the R-bit turned on. 


Link Establishment 


For purposes of the following discussion the 
node initiating the connection transmits first and 
is called the 'primary" node. The node being 
connected to is called the 'secondary' node. This 
distinction is made because the primary and 
secondary nodes use some of the fields in a slightly 
different way. This is a different use of these 
terms than is found in other protocol documents. 


The following chart shows a normal link 
establishment between the primary node whose address 
is A and the secondary whose address iS Be 


Primary transmits XID 
Secondary transmits XID 
Primary transmits I 


BA,XID-P --=> 
€2e- AB, XID 


Conflict Resolution 


Although unlikely, there is a possibility of 
the occurence of conflicting requests during the 
link establishment phase. This is not possible 
during other link phases. A conflict occurs if two 
nodes try to initiate a link with the other at the 
same time but with conflicting requirements. For 
example, one node wants to establish a half-duplex 
link while the other wants to establish a full- 
duplex link or the protocols they want to use are 
aii trerent . Even if both sides take the same 
recovery action this still does not solve the 
problem. One side must gain the upper hand. The 
resolution method chosen is that the node with the 
higher address gets its way and the node with the 
lower address must report to its higher level that a 
link was established but not with the desired 
specifications due to conflict. 
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Disconnect frame (DISC) 


The DISC frame is only sent during the link 
termination phase and it is the only type of frame 
that can be sent on links in the termination phase. 
I think this frame would better be called 'Unlink' 
because that is a better description of the function 
it performs. Connections (in my opinion) are the 
concern of higher protocol levels = not the datalink 
level. The DISC frame is only sent after the link 
has been established and indicates that the 
originator will no longer send or receive I and S-= 
frames on the link. It is sent with the Poll bit on 
by the primary node (The node initiating the link 
termination) and sent with the poll bit off by the 
receiving secondary node to indicate that it will no 
longer send I and S-frames on the link. 


The format of the DISC frame is the same as 
that of the XID frame described above except that 
the usage of the P, T and R fields is different. In 
the DISC frame the Reason field (R-field) indicates 
the reason for the disconnect when sent with the 
Poll bit on by the primary node. If the R-field has 
no bits turned on this is a normal link termination 
but if a bit or bits are on in the R-field, then 
this link is being terminated because of an error. 
The R-field bits are defined as follows: 


Bitnumber 76543210 
Oo000zY XW 


Where: 
1. If W is on, the originating node has received 
an invalid or non-implemented control field. 


2. If X is on, the originating node has received a 
frame with a prohibited I-field. 


3, If Y is on, the originating node has received 
an I-frame with a length greater than the 
maximum the node can support. 


4, If Z is on, the originating node has received a 
frame with an incongruous Nr. 


If any of the bits are on in the R-field, the 
P-field contains the control field of the frame 
received which caused the error condition and the 
T-field contains the following information: 


Bit number 7 6 5 4 321 0 
Vr 0 vs 0 


Where Vr is the next expected Ns value to be 
received and Vs was the next Ns value to be sent at 
the time the error was detected. 


The P,T and R fields are undefined (and should 
be ignored) in a DISC frame with the Poll bit off. 
Similarily, the P and T-fields are undefined ina 
DISC frame with a value of 0 in the R-field. 


Even though the node names are unnecessary from 
a technical point of view in the DISC frame, they 
are included in the Amateur Radio environment to 
give information to other nodes monitoring the 
channel as to who the two nodes are who have 
terminated the link between them. The names are 
also sent out when the link is being established as 
well. This is somewhat similar to the Amateur 
practise of identification at the beginning and end 
of each QSO. 


Unnumbered Information Frame (UI) 


The UI-frame is included in this protocol as a 
method of transmitting information when a link has 
not been established or for bypassing the_ normal 
handling of I-frames when a link is established. 
One example of such use would be a repeater 
identifying itself every few minutes # a type of 
broadcast message. It is included in the protocol 
because of a need in the Amateur Radio environment 
for such a function. 


Since UI-frames are unnumbered, they should not 
be ae ess cde whether or not they are transmitted 
with the Poll bit on or off. If one is lost, there 
is no way of recovering it. No error reporting is 
done for UI frames and the UI frame should only be 
passed on to a higher level when the data link is 
not established, not being established and not being 
terminated. For use as a type of general broadcast, 
the link address field in a W-frame should use the 
special general broadcast address of FFFF 
(Hexadecimal) as the first two bytes of the link 
address. If the broadcast is only intended for a 


specific area then the first byte should be FF and 
the second byte should be an area or group number. 
And if it is intended for a specific node then that 
node's address can be used in the first two bytes. 


Responses to polls 


When a node receives a frame with a P-bit on, 


it must respond. The type of response varies 
depending on the type of frame that contained the P= 
Dies The response frame does not have the P-bit on 


except in the case of the I-frame response where the 
P-bit is allowed. The responses possible for each 
type of frame containing a P-bit are shown in Figure 
4 following: 


Responding frame(s) 


Polling Frame Type 


I or RR or RNR or REJ* 
I or RR or RNR 

RR or RNR 

XID 

DISC 

none 

I 


* = REJ only used in full-duplex 
Figure 4 Poll Responses 


HALF-DUPLEX PROCEDURES 


Half-duplex links assume that only one side 
transmits at a time. For this reason they can be 
used on a single two-way communications channel. 
Half duplex protocols can also be used on 
independent transmission channels as well but full- 
duplex would be a more efficient method when these 
facilities are available. Channel sharing with 
multiple nodes require half duplex protocols. V-2 
provides a half-duplex multipoint protocol. This 
protocol can be used in a point-to-point environment 
as well with very little reduction in efficiency 
compared with a protocol only designed for point-to- 
point work. 


Information transfer 


When a node has one or more I-frames to send, 
it sends them in sequence and in conformity with the 
requirements described in "Frame numbering" 
previously. Since I-frames always require a 
response, the P-bit is turned on in the last frame 
of the transmitted sequence of I-frames. The 
exception to this rule occurs when it is necessary 
to transmit an S-frame with the P-bit on in the same 
transmission as well. either case, a receive timeout 
is started at this time as previously described in 
the section, "The Poll bit and receive timeout". 
The node then turns the link around and listens for 
a response. Note that the reception of an I-frame 
with or without the P-bit on demands a response. 


If the receive timeout expires meaning nothing 
was received, the node will not retransmit the 
previous frames but transmit an RR or RNR frame with 
the poll bit on and again wait for a response. This 
operation repeats itself until something is received 
from the other side. (The higher level of protocol 
is notified after every Nl consecutive timeouts.) 


When a response is received, the node starts 
transmitting I-frames  again,, beginning with the 
first unacknowledged I-frame. 


Not ready condition handling 


When a node becomes not ready to receive [= 
frames on a link it will send an RNR frame with the 
poll bit on at the earliest opportunity. Le 
permitted by the other side, I-frames may be sent 
along with the transmission of RNR but only the RNR 
frame should have the poll bit on in this case and 
it should be sent last in the transmission. The 
node then listens on the link. 


If the receive timeout expires, only the RNR 


frame with the poll bit on is retransmitted. ies Eee 8 
I-frame is heard the RNR frame with poll bit is 
retransmitted. (Note = the node may accept or ignore 


the. I-frame at its -discretion even though it is 
trying to tell the other side to stop sending them.) 
If an RR or RNR frame with the P-bit on is heard, 
the node should respond with I-frames followed by 
an RNR frame with the P-bit on if it can send I- 
frames or otherwise by transmitting two RNR frames, 
one with the poll bit on and the other with the poll 


bit off and start a receive timeout. (Note that two 
are required, one to respond to the poll from the 
other side and one to do a poll for the proper 
response from the other side. Finally, if an RNR or 
RR frame with the P-bit off is received this will be 
accepted by the node as an indication that the other 
Side is aware of the not ready situation and the 
node can go back to sending I-frames if it has any 
to send and is permitted to send them. Most of 
these actions can be deduced from Fig. 4 above. 


Note that no node is permitted to send I-frames 
after receiving RNR and before receiving RR. 


Ready condition handling 


When a node becomes ready to receive I-frames 
on a link it will send an RR frame with the poll bit 
on at the earliest opportunity. If permitted by the 
other side, I-frames may be sent along with the 
transmission of RR but only the RR frame should have 
the o011 bit on in this case. The node then listens 
on the link. 


If the receive timeout expires, only the RR 
frame with the poll bit on is retransmitted. Tf .an 
RR or RNR is heard with the poll bit on the node 
should respond by either transmitting I-frames 
followed by an RR with the poll bit on or otherwise 
by transmitting two RR frames, one with the poll bit 
off and the other with the poll bit on and start a 
receive timeout. If an RNR or RR frame with the P= 
bit off or an I-frame is received this will be 
accepted by the node as an indication that the other 
side is aware of the ready situation and the node 
can go back to sending I-frames if it has any to 
send and is permitted to send them. 


FULL-DUPLEX PROCEDURES 


A full duplex link requires two independent 
channels for the transfer of data. The full duplex 
protocol is designed so that it is possible for both 
sides to continuously transmit data to the other 
side Simultaneously. One channel is used for 
transmissions by node A for example and the other 
channel is used for transmissions by Be Because of 
the potentially continuous nature of these 
transmissions, it is usual that each node never 
listens on its own transmitting channel. However, a 
node may delay its transmissions if it has some way 
of knowing that its transmitting channel is 
unuseable. 


This version of V-2 only defines a point-to- 
POLE full-duplex protocol. This has uses in 
"backbone! linking for an Amateur Radio digital 
communications network and for satellite work. It 
is an option which does not have to be implemented 
in all nodes. Extensions to V-2 for multipoint full 
duplex operation are being planned but are not 
within the scope of this paper. 


Information transfer 


In full-duplex each node listens even when 
transmitting. Frame numbering and acknowledgment 
is SEM ai. “to halt-duplex except that 
acknowledgments are done 'on the fly' even while the 
other side is transmitting. 


A node sends I-frames in sequence until it 
either has no more frames to send or there are 7 
frames outstanding. At this point it will put the 
P-bat on in the final frame to request 
acknowledgement from the other side and begin a 
receive timeout. In order to improve throughput on 
links with a long turnaround delay - such as 
satellites, it is permissible to put the poll bit on 
in a frame before 7 frames are outstanding and still 
continue to transmit up to the maximum of 7 
unacknowledged frames. This technique is called 
‘pacing'. 


If the receive timeout expires meaning nothing 
was received, the node will not retransmit the 
previous frames but transmit an RR or RNR frame with 
the poll bit on and again wait for a response. This 
operation repeats itself until something is received 
from the other side. (The higher level of protocol 
is notified after every N1 consecutive timeouts.) 


When a response is received, the node starts 
transmitting I-frames again, beginning with the 
first unacknowledged I-frame. 


If a node receiving sequenced I-frames 
encounters a frame not in sequence it should send a 
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REJ frame at the earliest opportunity it gets. The 
node receiving the REJ should go back to 
transmitting the last unacknowledged frame and 
continue from there. The node should not transmit 
any more REJ frames until the reject condition is 
cleared by the receipt of the numbered I-frame 
indicated in the REJ frame. 


Not ready condition handling 


Not aacotl conditions are handled similarly to 
that described in the half-duplex environment except 
that the channel doesn't have to be turned around. 


Ready condition handling 


Ready conditions are handled basically the same 
as described in the half-duplex procedures. 


THE BIG PICTURE 


The datalink layer of protocol described herein 
is only one part of a complete communications 
aC As per the suggested ISO protocol 

ayering structures, this protocol only interfaces 
with the two adjacent layers in the node in which it 
is running and with the datalink layer on the other 
side of the link. 


The datalink layer receives data and orders 
from the Network layer immediately above it. The 
network layer is a ‘'higher' level of protocol and 
sort of acts like the datalink layer's ‘boss’. The 
datalink layer acts on these commands and reports on 
its progress and status as the job is done. When 
unusual conditions occur which the datalink layer 
can't handle it goes to its 'boss' for advice. 


The datalink layer passes data and commands to 
the next lower protocol layer - the Physical layer 
which in the Amateur environment is usually the HDLC 
Controller chip. The physical layer acts on the 
commands from the datalink layer and returns data 
and status information to the datalink layer by 
means of status lines and interrupts. 


The datalink layer also communicates to the 
datalink layer on the other side of the link. 


Even though it is only the third of these 
interfaces which is the subject of this paper, it 
should be realized that in a real implementation of 
a. datalink protocol. Chere are actually three 
difiterent. protocols anvolved:. i.e. the <chree 
communication interfaces. The type of protocols 
used for adjacent level communication are very 
system dependent but I will discuss in a general 
way, the type of information that is exchanged 
between the Network and Datalink layers. 


Interface with the Network layer 


Commands to the datalink layer and data to be 
passed accross the link are passed from the network 
layer to the datalink layer. The basic commands 
needed are: 


i Link -—- This is a command which orders the 
datalink layer to establish a link. The data passed 
with this command indicates what type of link 
(either Full or Half Duplex) is desired and the node 
name of the node to be linked to. 


2. Unlink - This is a command which orders the 
datalink layer to terminate a link. 


Status information and information received 
from the link in I-frames are passed to the Network 
layer from the datalink layer. The following status 
information should be passed: 


is When a datalink becomes established. The type 
of link and node name should be passed as well. 


2h When a datalink is terminated. The reason code 
and node name should be passed as well 


3. Whenever a predetermined number of consecutive 
timeouts (N1) on a link has occurred. 


4. When an invalid frame is received on a link. 


The above lists are not necessarily complete 
but should serve to give the reader a good idea of 
the type of information needed. Each implementation 
will have its own method of handling ‘these 
interfaces and it is not the intent of this paper to 
give detailed information as to how the information 


is to be passed. 
SAMPLE EXCHANGE 


The following example shows a V-2 exchange with 
NO ,CrLors .OF exceptional situations encountered It 
is beyond the scope of this paper to show an example 
of all pore types of exchanges. It is hoped 
thet. the. anformation in this “paper ..watll be 
sufficient for the reader to determine what the 
exchanges would be when receive timeouts, lost 
frames, invalid frames, and colliding frames are 
encountered. The A,C and I-fields are shown 
separated by commas. The address field is displayed 
pe eccenae The control field is represented as 
ollows: 


T (Ns) P (Nr) 


Where T is the frame type acronym and P is the 
pod. ‘bit. The (Ns) and (Nr) are only shown for 
frames which contain eg and the P is only shown if 
the poll bit is on (1 


The Network header sub-field in the I-field in 
I frames is shown in Hexadecimal characters and the 
rest of the I-field is shown in ASCII characters. 
The subfields in XID and DISC frames are shown 
separated by commas, the node names being in ASCII 
characters and the P, T and R fields in Hexadecimal. 
Time progresses downward in the following charts. 


The communication is between two nodes. Here 
is the pertinent information about the two nodes. 


Call sign VE7APU1 KA6M 
Node number 627B 68ED 


Exchange 1e 


This example shows) link establishment, 
information transfer and link termination. nN 
complete QSO. Arrows to the right indicate 
transmissions from VE7APU and those to the left 
indicate transmissions from KA6Me. 


68ED627B,XID-P,VE7APU1,KA6M  ,P=01,T=00,R=00 <---> 
<------ 627B68ED,XID,KAGM  ,VE7APU1,P=01,T=00,R=00 
68ED627B,1(0)P(0),0100,Hello Hank ----------------> 
Koereen-------- 627B68ED,1(0)P(1) ,0100,Goodbye Doug 
68ED627B,RR(1) ween eer nn nnn nnn nnn ene e nee weoeow==)> 
68ED627B, DISC=-P, VE7APU1,KA6M ,P=00,T=00,R=00 --=> 
<----- 627B68ED,DISC,KA6M  ,VE7APU1,P=00,T=00,R=00 


The first line shows VE7APU has entered the 
link establishment phase at request of the Network 
level and is trying to initiate (Poll bit is on) a 
half duplex link (Link Type = 00) with KA6M using 
version 0 level eres (Protocol = Ol). Because 
the Poll bit is on we know VE7APU has started a line 
timeout. 


The second line shows KA6M has entered the link 
establishment phase and is responding (the Poll bit 
is off) positively (the Reason field = 00) using 
version 0 level protocol. When this frame is 
received, VE7APU will enter the information transfer 
phase and cancel the line timeout. 


The third line shows VE7APU sending an I-frame 
with data to KA6M and demands a response from KA6M 
(the Poll bit is on). VE7APU starts a_line timeout 
at this time. When KA6M receives this frame it will 
enter the information transfer phase. 


The fourth line shows KA6M sending an I-frame 
with data and acknowledging correct reception of 
VE7APU's I-frame (Nr=1). It is demanding a response 
from VE7APU and starts a line timeout. 


The fifth line shows VE7APU acknowledging 
KAGM's I-frame by Scuei ls a Receive-Ready (RR) frame 
with Nr set to 1 has cancelled its receive 
timeout. The Poll bit is not on so VE7APU is not 
demanding a response from KA6M and so does not start 
a line timeout. VE7APU could have sent an I-frame 
at this point if it had any information to send. 


The sixth line shows VE7APU has entered the 
link termination phase on orders from higher levels 
and is sending a DISC frame to KA6M to request 
termination of the link. The termination has not 
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been caused by an error condition because the Reason 
field: is: 00: VE7APU is demanding a response from 
KA6M and starts a receive timeout. 


In the last line, KA6M enters the link 
termination phase when it receives the DISC frame 
and responds (Poll bit is off) with a DISC frame. 
After transmitting this frame, KA6M goes into the 
unlinked state. 


Since there are no further transmissions on the 
link we know that VE7APU has received the DISC, 
cancelled its receive timeout, and gone into the 
unlinked state. 


RESTRICTIONS AND LIMITATIONS 


1 This protocol will not function correctly if a 
node in the information transfer phase can hear 
frames from another node which is also in the 
information transfer phase and is using the same 
four-byte link address. Note that this would 
require two pairs (4) of nodes active on the same 
channel each pair using the same area number and 
node number. One node from each pair would have to 
be linked with one node from the other pair. 
Without going into any mathematical analysis I will 
state that, the probability of this. situation 
arising is extremely low. (Somewhat similar to the 
probability of the FCC or DOC issueing the same call 
to two different stations!). 


2. Although multiple links are allowed, a link will 
not be established to two nodes with the same 
address at the same time. The reason the link is 
not established is passed to the other node and 
corrective action could be taken = perhaps by 
changing the call sign suffix. 


3. Multiple links between the same nodes are not 
allowed. The need for this fieature is questionable 
as all necessary data traffic accross the link 
should be able to be multiplexed by the higher 
levels of protocol. Although not defined in this 
protocol, a node could masquerade as a different 
node by supporting multiple node addresses- and 
names by changing the call sign suffix. 


4, This protocol only supports datalinks between 
pairs of nodes. Thus it does not support 
conferencing or roundtable communication among a 
group of nodes. This function is normally provided 
by higher levels of protocol. The complications and 
problems encountered in providing data integrity 
with this service at the datalink level are severe 
and I do not know of any commercial or Amateur 
datalink protocols which do this. However, a form 
of roundtable operation could be implemented which 
does not guarantee data integrity. Fach node in the 
group could operate in unlinked mode transmitting 
and receiving data in UI frames. The members of the 
group could agree to all use a broadcast address 
FFxx (where xx=a group number) in the destination 
part of the link address and then only pass 
information from frames which had a link address of 
this form. Members of the group should be in good 
communication with each other because there is no 
way of recovering data from lost frames when using 
this method of conferencing. 


IMPROVEMENTS OVER THE OLD VANCOUVER PROTOCOL. 
1. Both full and half-duplex links are provided for. 
2. Multiple links are supported. 


3. Some multiple protocol support. 


4. Vastly increased number of link and _ node 


addresses. 

5.No coordination of node addresses is required. 
6 A rudimentary conferencing system is provided. 
COMPARISON OF V-2 AND AX-25 


IT am including this section because I am sure 
that many people will make comparisons and _ also 
because AX-25 is the only other Amateur Radio packet 
protocol which has ae published specification 
document. 


This comparison is difficult to do because 
despite statements in the literature that AX-25 is a 
link Devel “protocol, “it. cis, in: fact, a type sof 
network level protocol. AX-25 routes packets 
through a series of links from a source node to a 


destination node. Although AX-25 provides end-to=- 
end flow control, sequencing and data integrity, it 
provides no leery ke level error recovery, 
retransmissions, acknowledgements, sequence 
checking, etc. for any of the links in the chain. 
Only in the special case where the source and 
destination are connected by a single link could AX= 
25 be construed to be a link level protocol. In 
this special case, the end points of the connection 
become identical to the end points of the link and 
so the end-to-end connection facilities cannot be 
distinguished from the link facilities. Some 
comparison of the two protocols can be done when 
considering this special case. 


A document describing a Network level protocol 
for V-2 will be published later. Routing of packets 
through a network is one of the responsibilities of 
the Network level. Code for a Network level is 
being written at the present time for the VADCG TNC. 
Code for this link level protocol has already been 
implemented on the VADCG TNC. 


1. V-2 has a reduced protocol overhead compared to 
AX-25. A 4-byte fixed length address field as opposed 
to a 14-byte or greater address field in AX-25. 


2. V-2 has a facility to select full-duplex or half 
duplex protocols at link establishment. 


3. V-2 has a facility to select different protocols 
at link establishment. 


4 V-2 uses an addesssing and naming system for 
nodes. AX-25 makes no distinction between names and 
addresses. 

5. AX%25 has a network routing system. Vez Link 
level does not. 


6. V-2 does not bit shift call signs and other names 
when transmitted. 


7. V-2 makes use of the selective receive function 
of -the SDLC/HDLC ‘protocol -controller -chips to 
automatically eliminate frames that do not need to 
be checked. AX-25 cannot do this. For example, in 
this area, all call signs start with the character 
'v'. Using AX-25, this would mean that all frames 
transmitted in this area would have the same 
character after the initial flag in every frame. 
This effectively renders useless the selective 
receive function present on the protocol controller 
chips and forces the software to read into memory 
and examine every frame that is transmitted on the 
channel. 


SUMMARY. 


The general specifications of the V-2 protocol 
have been presented in this paper. As this is the 
first draft of a new protocol, some details may have 
been omitted. This document will be revised as 
necessary, to expand on areas not clearly presented 
and to include changes in the protocol. Those 
interested in obtaining the latest version of this 
document should contact the author. Anyone having 
questions or comments should do the same, preferably 
by writing. 


At the present time most of this protocol has 
been implemented in the VADCG TNC. The source code 
for this implementation is available on CP/M 8-inch 
diskettes. Anyone wishing to implement it on 
another system should contact the author directly so 
that the work may be coordinated. 


The author feels that V-2 link level is an 
efrive lent protocol both in terms of channel 
utilization and software requirements and that it 
is particularly suited to the Amateur’ Radio 
environment. It provides almost all the functions 
required by the ISO data link model without 
overstepping into functions in the domain of other 
layers. It is intended as a building block upon 
which higher levels of protocol can be independently 
developed as per the ISO proposals. 
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APPENDIX A. 


The CRC-16 algorithm divides the 7-byte 
character string of the Node Name by the following 
generating polynomial: 


168 BAZ ane? 


eS Sap 


This is the same polynomial used in calculating ' 


the FCS field by the various HDLC/SDLC protocol 
controller chips. In the calculation, integer 
quotient digits are ignored and the 16-bit remainder 
is checked to see that the first byte is not FF 
(Hexadecimal) and if it is, the bytes are reversed. 
If the first digit is still FF the value used is 


Program listing 


WHEN CALLED, 


LEAVES ITS NODE ADDRESS AT 'CRC' 


™e Ge ue BO 
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Node Address Calculation 


0000. This playing around with the value is done to 
ensure that none of the special purpose addresses 
beginning with FF are generated. 


Many of you out there may find this a little 
difficult to understand so I am including a sample 
assembly language program listing below which 
actually does the above generation for an_ 8080 
microprocessor. It should not be difficult to 
implement in other processors. 


ROUTINE TO GENERATE A NODE ADDRESS FROM A NODE NAME 
IT USES THE NODE NAME AT LOCATION 
UPON RETURN 

IT DOES NOT GENERATE ADDRESSES WITH FF AS THE FIRST BYTE 


"NODENM' AND 


; POINT TO 7=BYTE NODE NAME 


HAVE FINISHED WITH ALL THE CHARACTERS? 
(HEXADECIMAL) ? 


NO, RETURN WITH NODE ADDRESS IN CRC 
BAD LUCK, REVERSE THE CRC BYTES 


NO RETURN WITH NODE ADDRESS IN CRC 


0000 ADRCALC: ORG 0 
0000 210000 LX1 H,0 INITIALIZE CRC FIELD TO 0000 
0003 225100 SHLD CRC 
0006 215300 LX1 Fly NODENM 
0009 1607 MVI D,7 ; NUMBER OF CHARACTERS 
000B 7E LOOP: MOV A,M ; GET A CHARACTER 
OOOC CD2D00 CALL CALCCRC 3 GIVE IT TO CRC ROUTINE TO PROCESS 
OOOF 23 INX H ; POINT TO NEXT CHARACTER 
0010 15 DCR D : 
0011 Cc20B00 JINZ LOOP : NO, GO BACK TO PROCESS ANOTHER 
0014 2A5100 LHLD CRC : GET THE GENERATED CRC ROUTINE 
0017 7D MOV A,L : IS THE FIRST BYTE FF 
0018 FEFF CPI OFFH 
001A CO RNZ : 
001B 7C MOV A,H 3 YES, 
001C 6F MOV /A 
001D 26FF MVI H, OFFH 
001F 225100 SHLD CRC 
0022 7D MOV A,L NOW IS THE FIRST BYTE FF? 
0023 FEFF CPI OFFH 
0025 CO RNZ : 
0026 210000 ee ail H,0 : YES, EXCEPTIONALLY BAD LUCK 
0029 225100 SHLD CRC : SET NODE ADDRESS TO 0000 
002C C9 RET ; AND RETURN, JOB COMPLETE. 
: THIS IS THE BCTUAS CRC-16 CALCULATION ROUTINE 
002D E5 CALCCRC: PUSH 
002E 0608 MVI 38 
0030 4F MOV C,A 
0031 2A5100 LHLD CRC 
0034 79 CALCCRC1: MOV A,C 
0035 O07 RLC 
0036 4F MOV C,A 
0037 7D MOV A,L 
0038 17 RAL 
0039 OF MOV L,A 
003A 7C MOV A,H 
003B 17 RAL 
003C 67 MOV H,A 
003D D24800 JNC CALCCRC2 
0040. “Te MOV A,H 
0041 EE10 XRI 10H 
0043 67 MOV H,A 
0044 7D MOV A,L 
0045 EE21 XRI 21H 
0047 6F MOV L,A 
0048 05 CALCCRC2: DCR B 
0049 ¢€23400 JNZ CALCCRC1 
004c $5100 SHLD CRC 
004F POP H 
0050 C9 RET 
0051 0000 RC DW 0 i WHERE NODE ADDRESS IS PLACED 
0053 36453741 50NODENM DB "VE7APU1 3 NODE NAME 


005A 


END 
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WORKING "PACKET" 


ON OSCAR 10 


H. S. Magnuski, KA6M 

311 Stanford Avenue 

Menlo Park, CA 94025 
415-854-1927 


Abstract 


This paper summarizes the technical and operational 
aspects of trying to communicate via packet radio 
on the AMICON channel of AMSAT’s Oscar 10 
satellite. A calculation of effective throughput is 
made which considers factors other than the 
traditional Eb/No parameter. 


Background 


In the summer of 1983 the Phase IIIB satellite 
of the Radio Amateur Satellite Corporation (AMSAT) 
was launched and became known as Oscar 10. After 
some early problems, the satellite achieved a 
stable, highly elliptical orbit of 26 degrees 
inclination. The orbit achieved provides 
outstanding communications coverage, and multi-hour 
path openings between points on the globe. 


Within hours of the CUE oF 2OL the 
transponder, several well equipped amateurs who 
were both packet radio & satellite enthusiasts 
attempted to transmit digital information on the 
special channel reserved for packet radio use. The 
opening of the transponder was also a challenge for 
the rest of us (primarily computer types) to take 
advantage of this new communications resource and 
to learn what the words “signal-to-noise ratio" 
really mean. 


The author started assembling a satellite 
station in earnest in the Fall of 1983, and even 
though it would make a good story, this paper will 
concentrate on experiences of using the satellite, 
which has been the main activity since last 
December, when the last piece of the antenna system 


was put into place. 


The plan is to describe as many of the 
technical and operational parameters involved in 
using the satellite for digital communications as 
is possible. These comments and observations are in 
the form of a calculation which attempts to compute 
the probability of getting a packet through the 
satellite at any given instant. Please don't take 
the figures too seriously, as most of the numbers 
are approximations and there are obvious holes in 
the logic used to compute probabilities. 
Nevertheless, the reader should gain an 
appreciation of the technical challenges involved 
in working packet on Oscar 10, and see how much 
room there is yet for innovation and improving our 
systens. 


The sections which follow discuss the various 
factors involved in working packet, and _ in each 
case a number is derived which states the 
probability that the factor does not interfere with 
the successful transmission of that packet. At the 
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end of the paper all the probabilities are 


multiplied (independence of factors is assumed) to 
determine the overall probability of success. 


Satellite Visibility 


The satellite is in a highly elliptical orbit, 
with an apogee of 35,000 km. and a perigee of 3500 
km. The apogee sub-satellite point moves east about 
9 degrees in longitude per day, and the apogee sub- 
satellite latitude remains constant at around 25 
degrees. There are 2.06 orbits per day, but usually 
only one is visible for a given site, except at the 
transition where eastern passes change over into 
western passes, Antenna position during apogee is 
relatively stable, and only fine tuning is 
required. A printout or computer program is 
required to find out exactly where the satellite is 
during a pass, but the pattern is quite regular, 
and after a while one can almost sense where to 
point the antennas for the next orbit. 


A complete pass’ lasts almost ten hours, but 
during perigee the transponder is turned off, and 
experience has shown that packet work is only good 
around apogee plus or minus 2 1/2 hours or so. So 
the channel is only usable for about 5 out of 24 
hours, leading to a visibility probability of 5/24 
or. 9.21 


Normally the satellite is in Mode B (435 MHz. 
up, 145 MHz. down), but for four hours around 
apogee on Wednesdays and Saturdays it is put into 
Mode L (1269 MHz. up, 436 MHz. down) which is 
currently unusable for packet work. So the Mode L 
time is 8 hours in a 168 hour week, and thus_ the 
Mode B probability is 160/168 or 0.95 


A complete western horizon to eastern horizon 
series of orbits takes about twenty days, and the 
antennas point into a hill on the low western 
passes, and into an oak tree on the low eastern 
ones. SO scratch about four days out of every 
twenty, and the probability of not irradiating the 
neighbors becomes 16/20 or 0.8. 


Every month the orbits for the next month are 
computed at work and printed for 30 days in 
advance, but usually only after getting ready to 
work the satellite and finding that the calendar 
has expired. So one day out of thirty is lost, and 
the probability of having the right printout is 


29/30ths or 0.97 . 


As the orbit apogee passes east over the 180 
degree azimuth mark and works its way into Europe, 
the big boomers over there desense the receiver and 
make the power levels required to work packet more 
than the average ham can afford. So the probability 
of no Europeans is about fifty percent or 0.50 


The earthstation ground terminal equipment 
room is also the oM’s and XYL’s bedroom, and this 


means that late night passes are unusable. So, the 
probability of daylight is 16/24 or 0.67 . 
-=n finances required to buy ll __ this 


satellite equipment required the author to maintain 
his job, and the remaining time is roughly split 
between playing with the kids and playing with the 
radios. So, the probability of having some free 
time and not arranging a PPRS meeting or talking to 
a local ham club is perhaps 4/16or 0.25. 


Interference Conditions 


One of the major disruptive elements to the 
success of working with the satellite today is man- 
made electrical noise. This is particularly 
troublesome on packet, where a stray impulse can 
kill a complete frame. The main sources are autos, 
line noise, and the neighbors' mixmasters, electric 
vibrators and buzzsaws . Two meters is very prone to 
interference of this type, and a move to higher 
frequencies would be warranted for this purpose 
alone. The subjective impression is that roughly 
twenty percent of the time some static is in the 
air, and thus the no-noise probability is 0.80. 


The packet downlink is 145.830,which happens 
to be the favorite watering hole of some crusty old 
simplex fm'ers in this area, who can’t imagine why 
anybody would want to use their frequency, Most 
will move when asked, but others can't seem to 
comprehend that a five-way international qso could 
be in progress when the local channel sounds 
perfectly clear. The crusties seem to get their way 
about ten percent of the time, so the no crusty 
probability is 0.90. 


The receiving equipment has to be extremely 


sensitive, and unfortunately will pick up lots of 
stray radiation from unfiltered computer gear and 
unshielded, unboxed terminal node controllers, All 


the equipment purchased should be FCC Class B 
Certified, and all connecting cables should be 
shielded and grounds well maintained. One birdie 
from my modem on 145.760 serves as a nice test 
Signal source, but the rest may cause trouble five 
percent of the time. Therefore, the non-birdie 


probability is0.95. 
Station Equipment 


In order to get anywhere on packet, a decent 
antenna system is required with a mast-mounted pre- 
amp. The commercially available gas-fets have @ S dB 
noise figures, and are not too expensive, Most hams 
do not bother putting coax switches in their two- 
meter downlinks and setup their equipment so that 
the probability of transmitting into the gas-fet is 
near zero. Here are three creative excuses to tell 
friends after you've just smoked your high-priced 
gas-fet pre-amp: "My TAPR INC did a cwid when I 
didn't expect it", "My two-year old was playing 
with the microphone", and the classic "My 726 was 
on RB-TA instead of RA-TB". So the probability of 
having a functioning gas-fet is about 0.98. 


Most packet stations are currently using the 
AX.25 protocol at 1200 bps with 202-style FSK 
modems. There are a few stations who may still be 


using older protocols or different modems or slower 
speeds. The compatibility probability is therefore 
0.95 . 


The use of 202 FSK modems is currently the 
biggest barrier to successful packet work, as their 
theoretical and practical performance is poor in 
relation to other potential designs, Tuning is 
difficult, and different designs of the 202 have 
different performance levels. If one has stable 
equipment, a tuning indicator such as an “eye” 
pattern, and _ reasonable receiving equipment , then 
about nine out of ten packets can be recorded 
successfully. So, the frame throughput probability 
is 0.90. 


Channel Contention 


The packet community is relatively small at 
the time of this writing, only about a dozen or so 
stations have actually transmitted so far, So the 
probability of collisions with other traffic on the 


channel is quite small at the present time. 
However, the quarter second round trip delay 
permits two transmitters to start and collide 


without hearing each other's carrier, and this 
occasionally happens, Another source of collisions 
is TAPR boards left in full-duplex mode while 
running on a single frequency (not-split frequency) 
channel. So an estimate for the probability of no 
collisions is 0.95. 


Net Throughput 


If the above factors are considered independent, 
then the probability of a successful transmission 
is the product of each of the above factors. 
Multiplying all the items above, we compute a net 
transmission probability of ® 007059e This may not 
seem very high, but considering that twelve months 
ago the probability was zero, it i§ an infinite 
improvement ! 


If we also consider that in just one week 
there are 604800 seconds of potential transmission 
time on which we can place 72,576,000 bits of 
information, or 2,268,000 forty byte frames, then 
using the net number above implies that 16,009 
forty byte frames will get through the channel in a 
week. That's 640,392 characters of information, 
more than an average person can consume in a week 
given reasonable assumptions, 


Conclusion 
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Using the satellite for digital work has been 
one of the most interesting technical challenges 
the author has encountered for some time. It makes 
one appreciate the role satellites will play in the 
future, and opens up many new _ and interesting 
possibilities for information transfer, 


Clearly, new designs in modems and automation 
of the ground station control systems will vastly 
improve the throughput available on this resource, 


These are interesting technical challenges which 
lie ahead, and others are encouraged to add their 
contributions. 


A FACKET RADIO EMERGENCY COMMUNICATIONS SYSTEM 


Bob Neben KSBL 
126 E. Schantz Ave. 
Dayton. Ohio 45409 

(iS) 299-4436 


Introduction The roundtable is a ragchewing mode 
used with a group of operators. Each 
We have come a long way in the use of person keeps a 1 ist of stations so they 
Packet Radio. In the past few years we know which one to pass it to next. Other 
have gone from a handful of experimenters stations can break in to the conversation 
proving the practicality of the concept, if desired or a station could drop out, 
to hundreds and soon thousands of active however . it 1s courteous to sign off. 
Facketeers. Talking to one another to Conversations tend to reflect on what the 
help the synergism of ideas is valuable, last person said, since individual 
but the time is now to start building a stations do not normally keep notes, This 
viable system that will help the public is the Ring topography (Figure =) and it 
good. has limited usefulness since no station is 
"running the show". 
Topologies 
4 KKK KK KK 
We have an assortment of ways to kK 
communicate in Amateur Radio. The thing as 
we do best is talk to one another i .«@. one ' 
ham talking with one other ham. The media SueKt ee rhe eeTy FRE ENEN 
may be 2 meter FM, HF SSB, RTTY , SSTV, or a ee ea ee ee: 
whatever, This is the Foint to Point A EEERS rReEee® FORK KK 
topology (Figure 1). reer 
SESS ORS OOOO KK es 
k x x x KKK KK KK 
‘Station. 2 ko Ssssee5 ~~ &k Station 2 & : ze 
x x x x Figure 3. 
KKKKKKKKKKXKK KXKKKAKKKKKKK 
The directed net is typical of 
traffic handling situations. This is the 
ay Gunes Star topology (Figure 3). The net control 


station directs all traffic and no 
communication takes place without prior 
approval. This is a good way of getting 
the traffic to its destination, but at a 
high cost in terms of human efficiency,, 
Typical nets have upwards of a dozen or 
more stations. Since only two stations 
Can converse at the same time, the 
remainder must just listen to a lot of 
traffic that does not apply to them, 
except of course for announcement5 or 
bulletins. The efficiency of the net is 


This is the best communications 
network ever devised. There is only one 
conversation on the frequency; when one 
station is talking the other station is 
listening. There is no interference but 
should a retransmission be required, the 
communication could easily be handled by 
either station. The chances of the data 
being sent incorrectly is low because 
either can ask for retransmission, 
clarification or additional information iff 
NECEssat ye Paes te Ne “yp heee- amately terrible, As the number of stations 


transmissi one However, we also use other ; ; 

eopoIc gies increase and the traffic volume increases, 
° the efficiency drops still further. 

During Slack periods or when the volume of 


x 
OOK TOK K eee traffic eventually diminishes, these many 


1. See KX 2 Sessa —ee xX OS X 
operators ask themselves (and rightfully 
PEaURNe ee neene one ee so) “Am | really needed here?” Depending 
: on net discipline and managerial 
: techniques, a net could 1 ose many 
aie Pee rads Bieta aten oe aura Operators just before they are most 
5 ; needed. Worse yet, the operators may stay 
EEATENS SeeTEe LEE SEe around for that weather watch but won't 


show up for the next one. There must be a 


i e 2? 
Figure 2. better way. 
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IT want to mention another kind of 
that doesn’t exist in amateur 


nets one 

radio —- yet. It*s not implemented yet 
because it only applies to digital 
networks, Any station can transmit on the 


frequency (bus) and all stations are 
listening at all times. Because of the 
microprocessor present, stations will 
listen to what the station wants 
to or is directed to Listen to by the 
human operator. Stati on 1 can converse 
with station %. Meanwhile station 2 can 
talk to stations 3 and 4 Station 4 can 
monitor everyone and no station need 
listen or even be aware of any other 
station*s conversation. This is the Bus 
topology (Figure 4), but as far as the 
individual stations are concerned, it 
looks like the Point to F'oint topology 
(Figure 1). This is packet radio at its 
best and I would like to show you how you 
can apply this to emergency 
communications. 


KKK KK KK KKKKKKX KKXKKXKKKX 

x 1 » x 2? Xx x 3 xX 

X¥KXKKKXX XKXKKKKX XKKXKKKK 

' H H 
KKKKKEK KXKKKXX KX KKKKK 
kx 4 Xk x S xX x & 
KKKKKKX XKXKKKK XKKXKKX 
Figure 4. 


Disaster Operations 


no such thing aS a typical 
officials will 


There is 
disaster as various 
confirm; each one is different and unique. 
However, we can take a typical si tuation 
such as a flood. A flood affects a large 
area to some degree, but the flood is 
disasterous to only a localized area at 
any one time. This area is often densely 
populated although geologically limited to 
a few square miles. Consequently it 
affects many people, The first priority 
is warning these people of danger and if 
necesSary g evacuating them to shelters. 
Then comes monitoring conditions, 
maintaining the shelters, and finally 
cleanup. When things are habitable again 
the people return to their homes and the 
shel ters close down. The emergency is 
over. 


The type of radio activity varies 
widely during the operation. Standard 
operating procedures include lots of 
overkill and inefficiency but the job gets 
done somehow. Let's analyze the situation 
to see if there’s a better way. 


As soon as conditions warrant the 
Emergency Coordinator (EC) or their 
designee goes into the area and 
establishes the net in the temporary or 
permanent Emergency Operators Center 
(EQC). Local officials should already be 
collocated and have communications of their 
own to local public services including Red 
Cross and other agencies. Although 


only 
to listen 
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telephone service to these 

can keep the amount of radio 
Often however, 
either very limited 


slower, 
agencies 
traffic manageable. 
telephone service 
Or unavailable. 


is 


The EC communicates over 2 meter FM 
to various individuals or teams that are 
assigned to public officials, Red Cross, 


Damage Assessment Volunteers or Shel ter 


Managers. Sometimes our 2 meter 
communications is more reliable than that 
used by these various agencies. The 


problem comes from density of traffic, 


The E0Cs tend to be beehives of 
activity. Everyone wants to head the 
effort to get the job done. Your group 
will be getting communication requests 
from all these agencies for everything 
from trivial to critical. It *S near 
impossible to say"“no to the mayor. It is 
Our experience that the group with a good 
handle on this type of activity is the Red 
Cross. They have the disaster plans and 
experience and they work very well with 
groups such as ours. They also act as a 
clearinghouse on health and welfare 
Lrabiie:, 


The communication volume of traffic 
within the disaster area is’ higher than 
anywhere else. The farther you get from 
the disaster area, the less volume of 
traffic. With voice communication, there 
is no choice but to impact this high 
volume of traffic in the EOC. The high 
volume of traffic continues in the EQC and 
Surrounding area, however, people outside 
the area also get on the same repeater or 
frequency and make the rest of the net 
wait. Remember, only so many stations can 
actively be ona net with their traffic at 
one time before the frequency becomes 
saturated. The outlying stations with 
priority traffic are just as important as 
EOC priority traffic. Getting the 
activity away from the EOC doesn’t help 
unless you can get that traffic off 
frequency al so. We were partially 
successful by using 220 MHz as an 
"administrative frequency”, but that meant 
listening to voice conversations on two 
radios. Another 2 meter frequency ri gq 
won" t help because it will overpower the 
main 2 meter frequency and block 
reception. Is there a solution to this 
dilemma? Yes, packet radio! But how do 
you implement it? 


Voice and Facket 


For fast communication, there will 
never be a replacement for voice. Do not 
even think about asking the mayor to 
please type his or her message, Sq the 
net at the EQC will continue on 2 meters 
utilizing a base station and operators 
with mobile or hand held radios doing 
their thing. What we can do to relieve 
the bottleneck at the EOC is to establish 
an effective collocated packet radio 
system. How do we do this and how can it 
be used effectively? Remember the bus! 


Lots of traffic can be digitized 
including al 1 routine requests, shel ter 
traffic, Red Cross inquiries, damage 


assessment reports, ARES status, etc. We 
must be able to send our packets without 
affecting the 2 meter voice traffic or 
disturbing the EOC operators. I propose a 
paral 1 el system running the traditional 
voice on 2 meters FM and packet on 2290 
MHz (Figure ). 


KKKKKKKKKK 
* Red * x 
(or c3 6363 * 
RY) KOK 


CK KK KKK KKK KKK KK KKK 
XK Local * ARIES x 
K EQ *¥ EU x Xx 
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io 


Fiquire i. 
I chose 220 MHz for several reasons, 

2EQOMH2 can transmit wi thout i nterferi ng 

with 2 meter reception and visa versa. 


Most scanners cannot receive 220 MHz sa 
conf identiality of the information is 


protected. Alsa, it is 
impractical to simulcast the packet over 
the repeater voice ~ the packet attract5 
too much curiousity and it tends to 
Splatter on to adajacent channel. §&. 


somewhat 


The 2 meter voice net would be 
handled pretty much business as usual, 
with a few exceptions. Routine request5 
shoul d be signi f i cantl y reduced and there 
will be fewer people out there doing a 
better job. It may be hard to convi nce 
disaster planning councils that they can 
get more service with fewer people. 


FOCs usually have at least two people 
operating radios. Qne person serves as 
net control. and the other interfaces with 
officials;? monitors conditions? maintains 
status boards, etc . It is usuall.y 
difficult if not impossible for one person 
to serve all these functions. What’s 
needed is one operator to be net control 
while the other operates the keyboard. 
Ideally, the keyboard operator screens the 
request © $0 only the urgent information 
ties up the repeater. 


Lots of information can be 
transf erred via packet and a record of the 
traffic can be recorded to disk at _ one of 
the stations. If an item demands 
immediate attention at a particular 
station, the sender can ring the bell on 
that persons keyboard. Most traffic, 
however, will f al] in thecategories of 
either inquiry, status or update. One of 
the major differences between the voice 
net and the packet net is the lack of net 
control on the packet net. The packet net 
operates on the bus topology. However , 
every station should use the call sign 
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for use during the emergency. 


designated 


Any station can initiate an inquiry. 
Usually an inquiry is directed at the 
1 i kely respondent, but perhaps it should 
go to everyone. If every station uses 
their own call, we do nat have a vehicle 
far an al. l-call . If they use a particular 


call sign for the duration of the 
emergency, such as the club call or 
repeaters trustee’s call, then the 
extensions O-15 take on a new meaning. We 
can call selectively (i.e. E9BL~-3) or all 
call (KOBL). Status and update requests, 
however , i mply i nterf aci ng a computer. 
Computers and packet radio go hand in 
glove. Ry using a database program on our 


home or club microcomputer, we can manage 
disaster information like it has never 
been done before. Gone forever are the 
little scraps of paper all over t.he EOC. 
Instead we have neat, organized files that 
can be cal ] ed out 1 mmedi ately by any 
station. | t S a lot more professional 
check a listing rather than searching 
through a yellow pad. Chances are a 
computer 1 i sti mg will De more accurate and 
up to date, too. All these neat things 
using computers are of no avai 1 if we 
don't have a standard message format. 


to 


Messade Traffic 

How do we handle nessages? We really 
don’t want to put every message into an 
editor to rearrange it for our database. 
What is needed i 6 a standardized format, a 
standardized database program, anda 
program to check the incoming messages 
campatib:ility. If necessary? a human 
could rearrange the messaqe and/or ask for 
mi SSi ng i nf orrnati on. It woul d be nice tec 
keep the manual intervention under 10%. 


for 


Standardizing a format i more 
cl if f icul t than it looks. Remember we will 
want to have gateway access into this 
system. The ARFL messagegram does not 
adapt very well to packets. No 1 anger cdo 
we worry about wordcount Since we have our 
Frame Check Sequence guaranteeing error 
free reception. The same goes with 
sequence number since the computer can add 
the date/time. Calls are even handled 
automaticall ys But heading? text, and 
ending information needs to be 
standardized, 
left 


The military message format is 


over from the teletype and adapts nicel y 
to computers. The message contains 

heading inf ormati on that could be added by 
the computer including handling 
INnSERUCTLOnNS,:  OLigindating . station, 
date/time group? precedence (default to 


and desti nati on/addresses. The 
is free form and the message 
This is ideal 


routine). 
entire text 
ends with an ending sign. 
f or computers ! 


When the computer sees a meseage 
coming, it assigns it ta a file based on 
the header information which include:; type 


of message, date/time, originating 


Station, precedence and addresses. The 
text partion depends on the database the 
message will be ims i.@., damage 
assessment, shelter listing, ete. The 
error checking program needs to flag any 
discrepancies in this. 


Conclusion 


These messages and associated 
programs will form the data base that can 
be examined by any of the packet stations 
desiring information. Within a short 
period of time these data bases will 
contain a large amount of accurate 
information that will greatly aid the 
disaster effort and keep the workload 
manageable on the voice net. We will then 
be attaining a _ degree of efficiency never 
before realized, while serving the needs 


of our community. 
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AN APPLI CATION NOTE DESCRI BING A LOW POWER RS232 LI KE I NTERFACE 


Paul 


Newland, ad7i 


Post Office Box 205 


Hol ndel , 


Introduction 


Radio Anateurs are beginning to make use of 
| ow power (LP) mi cro- processor systens  ffor 
controllers and now have need for a LP serial 
interface to connect themto other LP terminals or 
conputers. This application note describes a LP 
serial interface that is conpatible wth 
conventi onal RS232 terninals plus the new "Jap" 
conputers that have only a "sort-of" RS232 serial 
interface. 


Problem Statement 


The "loose" global functional requirenents of 
RS232 are that a MARK or INACTIVE signal wll be 
transmtted as a voltage nore negative than -5 
volts froma | ow inpedance source and a SPACE or 
ACTIVE signal wll be transmtted as a voltage 
nore positive than +5 volts froma | ow i npedance 
source. A received signal into an inpedance of 
nore than 1 Kohm that is nore negative than -3 
volts wll be considered MARKING or |NACTIVE and a 
si gnal nore positive than +3 volts wll be 
consi dered SPACING or ACTIVE. 


Most inplenentations of a RS232 interface for 
anateur radio have used the 1488 driver and 7489 
receiver. Both these devices provide an interface 
conpatible wth RS232 specifications but neither 
part can be considered "low-power." An alternate 
interface inplenentation is required for a LP 
system 


An additional problem to overcone is_ that 
posed by sone of the new lap conputers, the Radio 
Shack Model 100 being a notable exanple. Sone of 
these lap conputers are using non-inverting, O3 
volt buffers, for their "RS232" interface drivers 
and as a result, they will properly receive 
signals from RS232 conpati ble equi pnent but nay 
not properly drive RS232 conpati ble equi pnent. 


The goal of this application note is to 
provide an interface that wll function well wth 
both these standard and sub-standard interfaces. 


Implementation 
A sinple and low cost driver and receiver can 


be forned wth LNS24 operational anplifiers. The 
power supply current drive for one package of four 


op- anps is less than 1 mA under no-load 
conditions. Two packages are required, one for 
receivers and one for drivers. This can be 


reduced to one package if sone output voltage 
limiting is provided for the receivers. For the 


receivers, the power for the op-anp should be 
taken froma +5 and ground voltage source. Power 
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for the drivers can be nost anything as long as it 
is bi polar. The positive supply of the driver 
op-anps should be taken froma +5 to +15 volt 
supply. The negative supply of the op-anp can be 
taken froma -5 to -15 volt source. If the 
mcro-processor system doesn't use a_ negative 
vol tage suppl y one can be developed using the 
Si | i coni x 7661 confi gured as a voltage inverter. 

The voltage range of the driver's output is from 
the positive supply, less 1.5 volts, to the ninus 
supply (i.e, for +/- 5 volt supply the output 
range of the driver would be +3.5 to -5 volts). 


A reference si gnal is developed for a 
slicing/limting point for use by the drivers and 
receivers. Figure 1 show how the reference is 
generated by R1, DO, D2, and an op-anp. The 
output of this op-anp wll rest at about 1.4 volts 
above ground wth a | ow i npedance. 


Figure 2 show. how the output drivers are 
conf i gured. They function sinply as an inverter 
and bipolar driver. The output wll swng from 
the positive supply (less 1.5 volts) to the 
negative supply. 1 provides current |i mting. 


Figure 3 show. how the input receivers are 
conf i gur ed. Note that receivers, unlike the 
drivers, have their power leads connected to +5 
volts and ground. The slicing/limting point is 
the reference derived in Figure 1. If this point 
was ground, instead of 1.4 volts, the interface 
may not work wth those termnals using 0-3 volt 
output drivers. Diodes 21 and D2 provide voltage 
limting causing the inverting input to be 
constrained to voltages between 0.7 and 2.1 volts. 
R1 provides the input inpedance control and 
current limting while R2 provides default si gnal 
condi tioning for leads that are often unterm nated 


(i.e., DSR, DIR, RTS, CTS, etc.). R3 and R4 
provides hysteresis while R5 pulls up the 
receiver's output to +5 volts to ensure 


conpati bility wth CMOS circultry. 
Conclusion 


RS232 interface such as this, 
less than 3 mA, 


Using a serial 
the idling current should be 


depending on load. The interface is sinple to 
construct and IS  conpatible wth RS232 
dri vers/recei vers as wel! as TTL/CMOS level (0-3 


volts) drivers often found in the new | ow pover 
"lap" conputers. Additionally, default condi ti ons 
can be set for untermnated receiver inputs. 
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Q CALL 


A Method of Providing Selective Calling for AMTOR 


Using Mode-B Collective Broadcast 


Paul 


(Bc) 


Newfand, ad7i 


Post Office Box 205 
Holmdel, New Jersey 07733 


1. Introduction 

This docunent defines a nethod of providing a 
Sel ective Group Calling (SGC) facility on top of 
CCIR Rec 476-3 (AMTOR) MODE-BcL1]. SGC _ has 
application on 80 neters and VHF where propagation 
provides consistent connunications. It provides a 
nechanism to allow a group of stations to 
interconnuni cate wthout printing nessages of 
other groups or individuals sharing the channel, 


There are two major features of a SC 
facility for CCIR 476 that nust_ be provided 
regardiess of the final facility definition. 


First, the facility nust be, or have the potenti al 
to becone, a recognized anateur radio standard. 
Secondl y, it nust be possible to provide the 
facility either wthin a CCIR 476 code converter 
or external to it. Below is a proposal that | 
feel neets these needs. First the major facility 
requirenents and constraints are outlined then the 
proposed transmssion and reception procedures are 
gi ven. 


2. Requirements 


The followng items were considered to be 


requirements for the facility. Addi ti onal 
requirenents may be added at a later tine _ but 
those listed below should be _ considered 
f undanental . 
2.1 Label ing 


The nethod used to i npl enent SG should have 
a distinctive | abel in the RITY terninol ogy. | 
have chosen Q-CALL as a label because it is a 
literal description of the proposed calling 
nechanism and it is unique to RTITY terninol ogy. 
Q-CALL uses for its SELCALL the letter Q foll oved 
by the 4 non-control characters of the CCIR 476 
"cal i" signal. 


2.2 Resistance to Falsing 


The sequence of characters that forns the 
SELCALL for SG should be sonething that would be 
unlikely to occur during nornal connuni cati ons. 


2.3 Group Calling 


The facility should have the ability to 
concatenate SELCALLs so that a true "group" 
calling capability exists rather than sinply the 
ability to send one SELCALL that nany stati ons 
respond to. When one SELCALL is shared among 
several users the calling station can not change 
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the groupings; this is undesirable. 


2.4 Generation of SELCALL Infornation 


The SGC SELCALL string should be such that it 
can be generated either internal or external to 
the CCIR 476 code converter wthout critical 
timng requi renents. 


2.5 Detection of SELCALL Information 


The SGC SELCALL string should be such that it 
can be detected either internal or external to the 
CCIR 476 code converter wthout critical tining 
requi renents. 


2.6 Generation of End-of-Communications Signal 


The SCC *' end- of - connuni cati on*' signal shoul d 
be such that it can be generated either internal 
or external to the CCIR 476 code converter. 


2.7 Detection of End-of-Communications Signal 


shoul d 
or 


The SGC *' end of--conmuni cation" si gnal 
be such that it can be detected either internal 
external to the CC!R 476 code converter. 


3. Q-CALL Proposal 


The signaling to provide these features can be 
sinple to inplenent. What follows are the current 
reconmended procedures the Q-CALL 
facility. 


for SGC 


3.1 Generation of SELCALL Signals 


Each Q-CALL SELCALL wll be forned by a CR, 


LF, LTRS, and the followng sequence repeated 8 
tines: "Q" "wxyz" "SPACE" . Wthin the sequence 
"SPACE" is defined to be the character SPACE, "()" 


is defined to be the character Q and "wxyz" is 
defined to be the four non-control characters of 
the CCIR 476 "call" signal nornally used for 


MODE-A = connuni cati ons. For group broadcast, 
several SELCALLs nay be concatenated by sending 
the first, then the secondl2], and so on until all 
desired SELCALLS have been transmitted. During 


"“SELCALL GENERATION' the inter-character tine nay 


not exceed 30 seconds. 
3.2 Generated Message Content 


All messages must begin with a CR or a LF 
character. The message nay be in any fornat 


except that the sequence NNNN is prohibited and 
during the nessage transmssion the Inter- 


character time may not exceed 30 seconds. 

3.3 Generation of End-of-Communicattons Signal 
End=-of=communication willbe sfgnafed by the 

transmission of the character sequence NNNN 

followed by the CCIR 476 MODE-Bc' end-of- 

communication signal (3 alpha characters). 


3.4 Detection of SELCALL Signals 


When the Q-CALL processor detects the 
sequence: "gr "“wxyz" nNSPACE"™ da Oi "wxyz" "SPACE" 
"Q" "wxyz", It wlll set a SELCALL-DETECT flagl3] 


indicating that a valid Q-CALL SELCALL has been 
detected, provided that the Inter-character time 
of the recelved characters does not exceed 45 
seconds. With In the Q-CALL sequence "SPACE" Is 
defined to be the character SPACE, "Q" Is defined 
to be the character Q and "wxyz" Is the four non- 
control characters of the CCIR 476 "call" signal 
normally used for MODE-A communications by the 
receiving station. When the Q-CALL processor 
detects that a CR or LF character has been 
recelved and that the SELCALL-DETECT flag Is set, 
aDATA-OUTPUT f | ag wil! be set. 


3.5 Message Reception 


Each teleprinter Soa ee recelved by the 
Q-CALL processor wi | be passed to the 
teleprinter[4] while the DATA-OUTPUT flag is set. 


3.6 Detection of End-of-Message Signal 


When no characters have been recelved for 45 
seconds, or the character sequence NNNN has been 
recelved, or the CCIR 476 MODE-Bc_ end-of = 
communications signal (3 alpha characters) has 
been recelved the DATA-OUTPUT and SELCALL-DETECT 
flags will be reset. 


4. Rational of Q-CALL Mechanism for Transmisston 
and Reception 


4.1 Selection of SELCALL Signals 


Any SGC SELCALL bullt on top of AMTOR should 
be something that makes use of the MODE-A "call" 
signal and Is eastly readable by an operator. It 
should be all letters case so that the Q-CALL 
processor does not need to worry about handling 
FIGS and LTRS characters[5]. The cal! should be 
repeated, without LTRS, FIGS, or any other 
extraneous characters for at least 8 repetitions. 
Eight repetitions ensures that the SELCALL wil] 
have a high probability of belng detected during 
less than optimum propagation conditions. CCIR 
476 "call" signals are often sent using MODE-Bc 
and repeated several times with only one space 
separating them[6]. For that reason, | have 
Included a "Q" and "SPACE" as part of the SELCALL 
string for a visual delimiter rather than Just a 
space. Including a CR and LF at the beginning of 
each SELCALL ensures that detectors provided 
external to a CCIR 476 code converter will "see" 
the SELCALL[7]. It also ensures that anyone 
monitoring the channel with conventional MODE-Bc 
equipment will be capable of reading all SELCALLs 
that are part of a group without having the 
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printer over-write Information at the end of a 


line. 
4.2 Selection of End-of-Communications Stgnal 


The NNNN Js easily detected by external 
equipment and the standby condition Is easily 
detected internal to the CCIR 476 converter. The 
time-out feature Is added to ald stations using an 
external Q-CALL detector. 


5. Procedures for a Q-CALL Transmission 


The Q-CALL transmissfon sequence should be 
functionally as follows: 


1. Set code converter to MODE-Bc transmit. 
Send CR, LF and LTRS. 


Send 8 repetitions of the "selective call" 
(ex., +++ QAADI QAADI QAADI...). 


If necessary send another new-!ine sequence 
and send any other SELCALL sequences needed. 
Repeat this step until all SELCALLs have 
been transmitted. 


Send the message (the first character of any 
message must be elther a line-feed or 
carrlage-return). 


De 


Send NNNN and switch to standby. 


EXPL 1017 EXAMPLE 


Be 888 8 88 8 88 3 38 SS SES BSS SS SS SVS SSS SVS SSSSSSSSS5 


((transmitter on, MODE-Bc)) 


QRA AD7| 

QAABC QAABC QAABC QAABC QAABC QAABC QAABC QAABC 
QWXYZ QWXYZ QWXYZ QWXYZ QWXYZ QWXYZ QWXYZ QWXYZ 
QWABC QWABC QWABC QWABC QWABC QWABC QWABC QWABC 
QWDEF QWDEF QWDEF QWDEF QWDEF QWDEF QWDEF QWDEF 


AB12C, W2XYZ, W2ABC, W2DEF DE AD7I 


A NEW STATION 1S NOW ACTIVE ON THIS FREQUENCY. 
W2GH! 1S ON USING SELCALL WGHI FROM NEW YORK 
CITY. W2GHI 1S OPEN MODE-A FROM 7PM TO 9PM 
LOCAL TIME AND OPEN FOR Q-CALL 24 HOURS A DAY. 


AB2C, W2XYZ, W2ABC, W2DEF DE AD7! 
NNNN 
((standby) ) 


nan — = -_= =. —_ mae ap «8 ue = 6 =o 
SPSS SSSS SSS StS SSS SS SSS SV SSSSSSSSSSSSSSSSSSSSS2=4 


-- NOTES == 


CCIR 476-3 defines MODE-B with two parts: 
COLLECTIVE (broadcast to all stations) and 
SELECTIVE (broadcast to one or a group of 
statlon(s)). | refer to MODE-B COLLECTIVE 
as MODE=-Bc and MODE-B SELECTIVE.as MODE~Bs. 
Throughout this document, terminology from 
CCIR .Rec 476-3 has been used, where 
appropriate, to reduce confusion. A major 


Tes 


change Is the use of the CCIR 476 term 
"call" signal rather than the nore connon 
SELCALL of AMQR 


effectively on a newline because of the CR 
LF wthin each SECALL string. 


Alternatively, the SELCALL- DETECT flag nay 
be set when the Q-CALL processor detects the 
sequence: "Q" "“wxyz" "SPACE" "QO" "wxyz", 
provided that the receiving station has 
user-selectable option of using the I onger 
sequence. 


Including the character that caused the 
DATA OUTPUT fiag to be set. 


this would be a problemfor systens that use 
ext er nal Q CALL processors and ASCII 
terminals. 


this is often done using MODE-Bc to tell 
party B what party C's "call" signals are. 


Sone CC!R 476 units wait until a CR or LF is 
det ect ed in  MODE- Bc before outputting 
characters to the teleprinter. 
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PACKET RADIO SOFTWARE APPROACH 


Robert M. Richardson, 


1984 ONWARDS 


W4UCH 


22 North Lake Drive 


Chautauqua Lake, 


ABSTRACT: 


The future of the software approach is 
‘crystal balled’ bv the author of 'Synchro- 
nous Packet Radio The Software Approach' 


(Vols. 1, 2,& 3) and 'The Gunnplexer Cook- 
book = A 10 GHz Microwave Primer.' Topics 
discussed include: 


- Bringing the software approach to the 
top of the learning curve. 

New generation microprocessors 
on the software approach. 

Low power requirement applications of 
the software approach to remote 
terrestrial repeaters and spacecraft. 
Implementing the software approach on 
very low-cost microcomputers. 

Future packet predictions year 2000 AD. 


influence 


APPROACHING THE TOP OF THE LEARNING CURVE: 


In 1982the software approach was at 
the 35% level of the typical learning 
curve. Here in early 1984, the software 
approach is about at the 85% level of the 
learning curve. 


With real-time zero insertion in the 
transmit mode, real-time synchronous’ to 
parallel byte conversion in the receive 


mode, and virtual real-time CRC generation 
and checking already accomplished, the last 
remaining bridge to cross is concurrent 


keyboard message input while in the receive 
mode decoding incoming synchronous 
packets. 


The voluntary constraint of insisting 
that the software approach work on a first 
generation, personal microcomputer such as 
the circa 1976 Model I TRS-80 without hard- 
ware modification, ruled out the possi- 
bility of using the Z=80's interrupt modes. 
Had this been possible, the last bridge to 
cross would have been an easy one. 
is yet another approach to 
keyboard input while in the 
receive mode that the author used in 
"Advanced Baudot Radio Teletype for the 
TRS-80' that was written in 1981. That is, 
using the idle countdown time between each 
mark and space sample to accomplish the 
keyboard scan and keyboard input 
processing. Using 100 speed Baudot TITY, 
this is indeed an easy programming task. 
At 1200 baud and up packet, it is a 
fascinating challenge. This is the 
approach we may use later this year. 


There 
concurrent 
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NEW GENERATION MICROPROCESSORS: 


With the introduction this year of the 
new Zilog Z-800 8/16 bit microprocessor 
starting off with a 10 MHz clock and 
planned growth to a 25 MHz clock ina year 
or so, the software approach's current baud 
rate limitation of 1200/2400 baud (and 4800 
baud using a 4 MHz clock) will be increased 
considerably. 


A 10 MHz clock Z-800 with its internal 


256 byte RAM cache memory (even with 
relatively slow ancillary chips) will 
easily run 9600 baud synchronous packet 
using the software approach. Considerably 


higher speeds will be possible as the 2Z800 
matures. 


New generation Very High Speed 
Integrated Circuit (VHSIC) chips developed 
under the Department of Defense' VHSIC 


now beginning to come off the 
These digital processing 
chips operating in the GHZ region, many of 
which are gallium arsenide medium scale 
integrated circuit chips, will extend the 
speed of the software approach to regions 
undreamed of today. Truly, the sky appears 
to be the limit. 


program are 
production lines. 


LOW POWER REQUIREMENT APPLICATIONS: 


The software approach reduces the chip 


count requirement of a packet operating 
system many fold. The entire terminal node 
controller (TNC) is eliminated which 
includes the TNC's microprocessor, 

SDLC/HDLC controller, vast EPROM, dynamic 
RAM, UART, and considerable numbers of 


ancillary support chips. 


The power supply requirement of the 
software approach is significantly less 
than that of the packet approach uSing a 
dedicated terminal node controller. Two 
obvious applications for a low power drain 
synchronous packet system are: 

1. Remote packet repeaters that utilize 

solar cells, wind generators, fuel 

cells, or fueled generators for local 

Power (forgot water wheels/turbines), 

2. Spacecraft repeaters (about as remote 
as you can get) which rely solely on 
solar cells for power. 


By using the new CMOS version of the 
Z-80 microprocessor, CMOS dynamic RAM, CMOS 


ROM to hold the software approach »rogram, 
and CMOS ancillary chips, the power drain 
of a remote packet repeater would be 
determined almost solely by the repeater's 
transmitter RF output requirements. 


If you have a very tight power budget 
to work with, we suggest that it might be 
wise to consider the software approach. 
Though not yet available in the CMOS 
version, the GLE Electronics PK-1 packet 
radio controller, which uses the software 
approach in EPROM for both the Vancouver 
and AX.25 protocols, draws a total of only 
200 milliamps at 12: VOLES: “DC. "CNOS comld 
reduce the power drain 1 to 2 orders of 
magnitude, 


SOFTWARE APPROACH ON LOW-COST MICROS: 


Should be an easy task for most 
experienced assembly language programmers 
using any one of the popular cross 
assemblers on the market today. Most all 
of the low-cost micros have at least one 
port already decoded for cassette input and 
OUTPUT. 


The software approach only requires a 
single port and if only a single bit is 
available (some very low-cost micros 
require that the user manually turn the 
cassette on and off), the software approach 
may still be implemented if the user is 
willing to manually switch from transmit to 
receive and vice versa. 


Low-cost micros come with varying 
amounts of memory, Most that we know of can 
be expanded to a minimum of 16K and include 
some version of Basic in ROM. Many can be 
expanded up to the 48K memory level. 


16K of RAM memory is about the minimum 
that the 'economy' version of the software 


approach would require for home station 
operation. If only the automatic 
forwarding function of AX.25 is used 
(strictly for packet repeater operation), 
then the program could be probably 


shoe-horned down to about 4K of memory by a 
truly ‘tight code' programmer. 


The economy version would do away with 
many of the niceties and convenience 
options that the 48K MEM disk I/O version 
offers, yet would be adequate for the 
newcomer with a modest budget. Further, 
this very low-cost approach would probably 
lure many newcomers into the packet fold. 

We are NOT suggesting that the 
'chiclet’ key type of micro be used for 
packet, but rather the next level of 
low-cost micro, at least with a normal size 
typewriter keyboard might be implemented 
with the software approach loading into 16K 
of memory via cassette. 


We encourage you enterprising 
packeteers out there in amateur radio land 
to have a go at this worthwhile project. 


Just imagine tens of thousands of low-cost 
microcomputer sows ' ears magically turned 


overnight into AX.25 silk purses by your 
stalwart programming prowess. It would be 
a giant step forward for packet. If you do 


NiGie choose to do it, there are some 


comnercial firms who will. 


CONCLUSION: 


the future of packet radio 


Seriously, 
room for all 


(which is tomorrow) has 
varieties of radio amateurs whether they 
are appliance operator inclined, of the 
moon bounce variety, or even quadrature 
phase shift keying oriented on 1296 Milz and 
up. Not only is there room for all kinas, 
packet radio needs all kinds to reach the 
level of acceptance it deserves in a timely 
fashion, 


Packet radio in the year 2000 AD? 
Only 16 short vears away. Here are cur 
same of our ‘if wishes were horses' packet 


predictions. 


1,.Fullv authorized on all the low bands 
using 309/600 baud MSK. Synchronous 
packet totally replaces asynchronous 
Baudot, ASCII, and AMTOR, 


2. VHF bands using 9600 baud and un MSK. 
19.2K baud packet is the standard much 
like 1200 baud packet today. 


3. Low altitude orbit amateur satellites 
a thing of the past (like predicting 
the demise of buggy whips after the 
automobile went into mass production), 


4. Level/layer 3 packet fully implemented 
via terrestrial and satellite links. 
Hopefully, this will occur long before 
the year 2000 AD. 


§. 2300 MHz amateur band serves as uplink 
to geo-stationary satellites with 
multiple access and intra-satellite 
packet forwarding capability. Down- 
link broad beam in 1215 MHz band and 
spot beam in 5650 MHz band or higher. 


6. Other microwave amateur bands: 
"Crystalmatic frequency stabilization" 
system allows 10 GHz and 22 GHz solid- 
state narrow-band packet communication 
systems to be used for amateur point 
to point packet communications. This 
is already available today using low 
power Gunnplexers. 


7. The software approach? Still alive and 
well because it is a cost effective 
approach to amateur packet radio 
communications. The intellectual 
challenge is a side benefit for those 
who like to understand what they are 
doing and who like to climb mental 
mountains because they are there. 
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PACKET RADIO # THE 3RD GENERATION SOFTWARE APPROACH 


AX. 


Robert M. Richardson, 


25 PROTOCOL 


W4UCH 


22 North Lake Drive 
Chautauqua Lake, 


ABSTRACT: 


The 3rd generation 'software approach@ 
to 1200 baud packet radio using the AX 25 
protocol is described. This approach 
consists of software written in assembly 
language to replace the Tucson Amateur 
Packet Radio (TAPR) terminal node 
controller (INC) which includes: 
TNC's 68093 microprocessor. 
TNC's costly SDLC/HDLC controller. 
TNC's large 25K to 35K EPROM. 
TNC's dynamic RAM. 
TNC’s RS232 UART 
TNC'sancillary support chips. 


The software approach also eliminates 
the need for an RS232 interface (approx. 
$100 cost) on the host microcomputer which 
may be either a Model I or Model MIII 
TRS-80. The RS232 interface is replaced by 
a low cost port zero encoder/decoder (parts 
cost approx. $15) which is used to 
interface the microcomputer to a home brew 
modem (parts cost approx. $15) which may 
use the low cost EXAR 2206/2211 AFSK 
modulator and demodulator chips that are 
used in both the Vancouver and TAPR 
modems. 


A more sophisticated modem of the 
users choice for noise-prone and fade-prone 
circuits such as OSCAR 10 may be required 
LOL satisfactory weak-signal operation, 
though the author regularly and reliably is 
able to work the Toronto, Canada area 
packet repeater, VE3PKT, some 110+ miles 


iis Caines 

A number of major improvements for the 
spac generation packet radio software 
approach which are included in Volume 2, 
"Synchronous Packet Radio Using The 
Software Approach = AX.25 Protocol,' are 
described in detail. 

INTRODUCTION: 

Just as the TAPR terminal node 
controller has undergone a number of 
iterations and improvements Since slices 
inception, the ‘software approach' has 


followed a Similar course. Looking at a 
typical exponential growth/learning curve, 
1984's software approach is about 85% up 
the vertical scale and approaching the knee 
of the curve whereas the software packet 
program written in 1982 was at 


level. This decided improvement was 


the 33% 
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largely motivated by the disclosure in 1983 
to the public at large, of the brilliant 
AX.25 protocol by Terry Fox, WB4JFI et al 
at the Second ARRL Amateur Radio Computer 
Networking Conference. The AX.25 protocol 
is to packet, what SSB was to amateur radio 
communication techniques in the mid-1950's; 
i.e., not revolutionary, but a giant 
evolutionary step forward. We doff our 
collective hats to the many authors of the 
excelllent AX. 25 protocol. 


The 3rd generation software approach 
has a Significant number of improvements 
over the lst generation that was presented 
in Volume 1, *Synchronous Packet Using The 
software Approach - Vancouver Protocol.' 
These improvements are: 

1. Receive ies synchronous to parallel 

byte conversion is done in real-time. 

Automatic; AX.25 repeater if your callt 

SSID in repeater segment address field 
. CRC generation and checking is done in 
virtual real-time 27 times FASTER. 
AUTO Breton mode option for unattend- 
ed operatiion with T2 timer auto reset. 
FORMAT on/off option for receive video 
recognizes or ignores C/R's and L/F's. 
Multi-frame packets are input from the 
keyboard same as single frame packets. 
Information field length may be set 
from the menu from 1to 256 bytes. 
Frames per packet may be set from the 
menu from 1to 7 frames. 
NOW connected mode displays and stores 
only the information field each frame. 
NOT connected mode displays and stores 
everything except flags and CRC bytes. 
11. Disk I/O from within the program. 


2. 


10. 


Here is a rundown of major improvements. 


A. REAL-TIME SYNCHRONOUS BIT CONVERSION: 


received packets were 
stored in memory using the byte per 
received bit approach. This was a great 
teaching tool as it allowed the user to 
visualize the SDLC received bit pattern a 
full page of memory (1024 bytes per page) 


In Volume 1, 


at atime using the program's edit/modify 
mode. Each and every received bit, flags, 
data bits, and zero insertion bits were 


there to be seen. Some times a picture is 
worth a thousand words and it was quite 
useful for the newcomer to synchronous 
packet radio to be able to see the 


brilliant IBM synchronous data link control 
concept in action. 


So much for the pluses of this approach. 
Its disadvantages were that it took 
precious time to decode tne data after the 
packet had been received and more 
importantly ate up memory faster than a 
hungry bear. The time factor was not 
noticeable with single frame packets, but 
was measurable when multi-frame packets of 


maximum length were received. The 
voluminous memory requirement for the byte 
per received Dale storage was this 


approach's major detriment. 


Along comes Sir Galahad, ne Gil 
Boelke-W2EUP, on his white charger to 
rescue Volume 2 from the memory monster. 
Not only does W2EUP'S superb real-time 
serial synchronous bit to parallel decimal 
byte conversion subroutine solve the memory 
problem, but. Lt also eliminates the 
measurable time delay for decoding long 
multi-frame packets. 


The author's software digital 
phase-locked loop (DPLL) used in Volume 1, 
was again used in Volume 2 with only 


cosmetic changes. It was an cid 
trusty/reliable friend and allowed the user 
to copy 1200 baud packets whose timing was 
off as much as 10 percent from the norm. 
It is somewhat analagous to the hardware 
approach used by the Intel 8273 dedicated 
SDLC ‘controller MST -chip. Figure 1 
illustrates two, bit time periods where 
there was a change from space to mark (mark 
and space are used only as colloquial terms 
Since SDLC/HDLC are only interested in the 
relative change and not the absolute 
value), 


Fach 1200 baud 833.333 microsecond bit 
time is divided into quadrants with each 
Quadrant testing for a change of state 
(mark or space) of the incoming serial 
synchronous data bits Ideally, all 
transitions from mark to space or vice 
versa, will occur exactly between quadrants 
2 and 3, so that the bit sample taken after 
time 4 is exactly at the dead-center of 
each incoming bit time. Since our software 
DPLL is somewhat less than ideal/perfect, 
it adjusts the variable time 4 countdown 
value so that the average bit transition is 
usually between time 2 and time 3. Mie Tae 
occurs during time 1or time 4 a much 
larger correction is made to time 4 to 
bring the sample time back to near 
dead-center again. 


All bit processing is done by the 
program between time 4 and time 1. The bit 
processing time is less’ than 10% of the 
total 833.333 microsecond bit time period 
so has little or no effect on the DPLL as 
long as each processing tine period is 
exactly the sane. Equalizing time delays 
in the processing routine are used to 
insure that the processing time period 
is exactly the same. Equalizing time 
delays in the processing routine are used 
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to insure that the processing time period 
remains constant. 


The DPLL's fixed time constants of TYME 
1, 2, and 3 with values of 23 decimal are 
for the Model I TRS-80. The Model III with 
its slightly faster clock uses decimal 28 


For TYME Le. 2; and a The DPLL 
subroutine's calculated TYME 4 countdown 
correction values are the same for both 


Models. 


Figure 3 is the commented source code 
for the 1200 baud real-time synchronous to 
parallel decimal conversion, most of which 
from lines 900 to 1880 were generously 
contributed by W2EUP. The author's DPLL 
begins at the label TYME in line 1880 and 
runs through the end of this subroutine. 
Eig. 3 starts off with MODE which is the 
beginning of the receive mode subroutine. 
All the folderol before line 900 are simply 
the cues to tell you what the program has 
done automaticaly (if in the NOW CONNECTED 
mode of operation), such as displaying 
<CONNECTION ACK> on video if the program 
was in the AUTO ON mode, and so forth. 


In the receive mode, the program 
continually cycles between NEWONE in line 
690 and line 840/860while looking for a 
valid (mark or space) change in the input 
from the EXAR 2211 demodulator via port 
zero. When a change is found, the program 
progresses to FL1 where it searches for the 
first opening flag. If the DCD (data 
Carrier detect) from the EXAR 2211 drops 
before a flag is found, it starts all over 
again at BEFOR1. 


Once an opening flag has been found, 
it proceeds to FL2 where further opening 
flaas are ignored as this subroutine is 
searching for the first non-flag data byte 
in the frame. Again, if DCD drops it starts 
all over again at BEFOR1. When the first 
non-flag byte of the first frame is 
assembled, line 12/70 jumps of to line 1600. 
The IN1 subroutine is the work horse of 
this real-time receive mode decoding 
section. 


Only the first flag that is decoded by 
FL1 is stored at 40959 in memory. Decoded 
packet data bytes are stored from 40960 on 


up in memory by the IN1_ subroutine. All 
converted bytes except frame ending flags 
are stored here for each packet. Fach 


frame's ending flag location is stored 
sequentially in memory beginning at STORE. 
packet has been 


After the entire 


decoded in real-time, IN1 exits to the 
MOVEM subroutine that is not shown in 
Figure 3 aS it is too lengthy for this 


conference paper. MOVEM's function is 
determined solely by the mode the operator 
has selected; i.e., NOW connected or NOT 
connected. 


B. AUTOMATIC REPEATER + NOW/NOT CONNECT: 


In the NOW connected mode of operation 
each frame is CRC checked and if ok, the 
repeater segment of the address field then 
tested. If it contains your call letters 
and SSID, then the repeated bit is set for 
each frame, the CRC recalculated for each 
frame, and the total packet retransmitted. 
As such, your packet station serves as an 
automatic repeater. Video will display 
<FORWARDING> when this function is used. 
If the automatic repeater function is not 
called, the program then tests the other 
station's and your call letters + SSIDs 
(and repeater call letters + repeated bit 
where applicable) and if ok, sequentially 


tests each frame's control byte to 
determine the function. 
Let's assume it wasS an information 


frame. Since you know who you are 
connected to, (the other station's call 
letters are displayed by the program in the 
lst three right hand columns of Figure 2's 
main menu in both the auto and non-auto 
modes), ONLY the information field of each 
frame is displayed on video and stored in 
high memory. The ACK is then transmitted 
automatically while the video display 
remains in the receive mode. See Figure 2 
for the main and shift menus. 


In the NOT connected mode, everything 
except the flags and each frame's CRC bytes 
are displayed on video. The call letters 
and repeater if used, of the address field 
are right shifted one bit so as to display 
their real ASCII values. If you selected 
the NOW FORMAT option from the main menu, 
all carriage returns and line feeds are 
recognized and acted upon on the video 
display, If NOT FORMAT, they are ignored 
and the TRS-80 symbols for ASCII 13 and 10 
displayed. NOW or NOT format may be used 
in either the NOW or NOT connected modes. 


Intentionally, there is no CRC check 
of each frame in the NOT connected mode as 
we wish to see everything the EXAR 2211 is 
capable of demodulating, good and bad, up 


to 4K bytes in length per packet. 
Simultaneously with the video display 
function, all received bytes are stored 


sequentially in high memory beginning at 
53248 decimal. Each received packet with 
CRC bytes may be inspected a full 1024 bvte 
page at a time by going to the edit/modify 
mode via press M from the main menu to go 
to 40960 in mid-memory. Press ENTER to 
move up a page or the MINUS key to move 
down a page. 40960+ is re-used bv each 
received packet. To inspect everything 
sequentially received so far (up to 12 
pages = 12,288 bytes) except flags and CRC 
bytes, press shift M to take you to 53248+ 
in memory and then page up or down in 
memory as you wish. The BREAK key will 
return you to the main menu from the 
edit/modify mode. 


C. HI-SPEED CRC USING THE BYTE-WISE LOOK- 
UP TABLE APPROACH SUGGESTED BY PEREZ: 


Volume 1's software CRC generation and 
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checking subroutines emulated the hardware 
approach used by IBM and the other SDLC 
controller chip manfacuturers. By that we 
mean the software aprroach emulated the 
same multi-shift register format and 
derived the CRC value ona bit by bit 
basis. It worked very well thank you, but 
it ate up precious time, especially with 
long multi-frame packets. 


One approach we tried was to do the 
transmit mode CRC generation in real-time 
while the frame was actually being sent, 
just as the Intel 8273 SDLC controller chip 
does it and just as this program does the 
zero-insertion in real-time. It worked, 
but it solved the wrong problem. fThe real 
problem lay in the receive mode CRC 
checking time delay that was measurable 
when maximum length multi-frame packets 
were being received. 


Much like Sir Galahad saving the SDLC 
maiden from the memory monster, along comes 
Sir Lancelot, ne Aram Perez, and saves’ the 
CRC damsel from the time eating dragon. 
The June '83 issue of IEEE Micro Journal 
had a fascinating paper by Aram Perez that 
covered his 'byte-wise' CRC look-up table 
approach Lor the CRC16 (Bisync) 
polynominal. Without too much difficulty 
we were able to generate a look-up table 
for the IBM SDLC polynomial used by the 
AX.25 and Vancouver protocols. 


The results? An incredible 27 times 
SPEED-UP..of both CRC checking and 
generation compared with Volume 1 of the 


The majority of this 


software approach. 
courtesy of 


section and its subroutine is 
Mr. Perez' excellent paper. 


The CRC we will cover will detect: 


~# all one or two bit errors. 

all odd number of bit errors. 

- all burst errors less than or equal to 
the the degree of the polynomial used. 

# most burst errors greater than the 
degree of the polynomial used. 


What this adds up to in AX.25 protocol 
is a probability in the vicinity of 10 to 
umpteenth power, that if the CRC tests ok, 
the received frame that was CRC checked is 
correct and identical to that which was 
transmitted. If it is good enough for 
banks to transfer funds by electronic mail 
(it is), it should be good enough for us. 


HERE IS HOW IT WORKS: 


In a protocol utilizing “the cyclic 
redundancy check, the message to be 
transmitted between the last opening flag 
and the closing flag in each frame is 
considered to be a binary polynomial M(X). 
It is first multiplied by X to the K power 
and then divided by an arbitrary generator 
polynomial G(X) of degree K. This yields a 
quotient Q(X) and a remainder R(X) divided 
by G(X). All arithmetic is done in modulo 
2; i.e., the results of subtraction are 


equal to the results of addition. The 


equation looks like this: 


x M(X) R(X) 
| = 200K) Ge i a 
G(X) G(X) 
The @® sign signifies addition in 
modulo 2 arithmetic. Simplifyina this 


equation yields: 
X M(X) ® R(X) = Q(X) G(X) 


Where R(X) will always be of degree K 
or less. The CRC algorithm calculates R(X) 
and tacks these 2 bytes onto the end of the 
frame to be transmitted. Since as 
illustrated above, x M(X) ® R(X) does 
indeed equal Q(X)G(X), the original message 
with the 2byte CRC tacked on will be 
evenly divisible by G(X), IF and only IF no 
bits were erroneously received. Using the 
IBM SDLC (CCITT) polynomial as shown below, 
the remainder will always be 61624 decimal 
IF the frame was received correctly. 


IBM SDLC AND BISYNC GENERATOR POLYNOMIALS 


NOTE the [ figure = exponentiation 
IBM SLDC (CCITT) X[16+X[(12+X[5+1 
SDLC REVERSE X¥[16+X[11+X[4+1 


X(16+X(15+X[2+1 
X[16+X[14+X[1+1 


CRC1 6 (BISYNC) 
CRC16 REVERSE 


The reverse polynomials are the same 
as their big brothers, except taken in 
reverse order. Since the rather simple CRC 
arithmetic is done in modulo 2, it is quite 
easily implemented by the MSI chips used by 
both Vancouver and TAPR TNC boards. The 
former using the Intel 8273MSI chip and 
the latter using the Western Digital 
1933/1935MSI chip. 


One of the drawbacks to using the 
hardware rather than the software approach 
is that the user never knows what the CRC 
value is that he/she transmitted or 
received. Some packet operators could care 
less, but then again, some radio amateurs 
prefer to fully understand what they are 
doing. 


This program allows you to read _ out 
exactly what the generated and received CRC 
values are for every packet that is 
transmitted or received by using the 
edit/modify mode. 


Unfortunately there is no such thing 
as ‘free lunch.' The price we have to pay 
for this extremely FAST CRC subroutine is a 
modest bit of memory for the 512 bvte 
lookup table. Nevertheless, it is a small 
price to pay for the near ‘speed of light' 
swiftness gained. Again, this approach is 
27/times faster than the bit by bit CRC 
routine used in Volume 1. 

Both received frame CRC checking and 
transmit frame CRC generation are each 
quite simple using Aram Perez' byte-wise 
approach modified for IBM SDLC (CCITT) 
polynomial. Let's look at the transmit 
mode CRC generation first. 


All frames to be transmitted are first 


moved to MEM location 43008 + a frame at a 
time, then the CRC is generated, and 
inserted. For multi-frame packets, a frame 


is moved, the CRC generated for that frame 


and inserted, and then the next frame 
moved, CRC generated and inserted, SVG, 
This only requires milliseconds of 


real-time. 


The memory location denoted by the 
label ENDCRC always contains the generated 
CRC value of the packet just transmitted IF 
it was a single frame packet or the 
generated CRC value of the last frame 
transmitted if it was a multi-frame packet. 
If the current packet being transmitted is 
a single frame info packet and the program 
in the NOT connected mode, the CRC value in 
decimal will be displayed on the top line 
of video, and the packet immediately below 
it while it is being transmitted. 


Why bother with displaying the CRC 
decimal value in the unconnected mode? 


Only for convenience. Sometimes it 
can be very useful for the station at’ the 
other end who is trouble shooting his/her 
receive mode system. Even the hardware 
approach using the Western Digital WD-1933 
or Intel 8273SDLC chips can on occasion 
have problems with its real-time CRC. Some 
of the early SDL controller chips 
exhibited this type of problem. 


Figure 4 starts off with the commented 
source code for generating the two IBM SDLC 
CRC bytes for each frame to be transmitted. 
Almost the same routine is used for testing 
the CRC value of each incoming frame of 
each packet. See lines 870 through lines 
990 of this subroutine for the receive 
mode CRC check. For either transmitted or 
received frames, this CRC -f#iunceion:. 1s 
accomplished virtually in real-time. 


D. TRANSMITTING MULTI-FRAME PACKETS: 


Data for the information fields of all 
multi-frame packets originates in low 
memory beginning at 17408 decimal. 12288 
LO-MEM bytes are reserved here for the 
automatic multi-frame transmit function. 
Data may be input directly from the 
keyboard by pressing shift L to go to 17408 
in LO-MEM in the edit/modify mode and then 
typing away till done, or data may be input 
from disk without leaving the program. 


Referring to Figure 2's main menu, the 
operator presses G to input the number of 
frames per packet 1 = 7,and then presses N 
to input the information field length of 1 
to 256 bytes per frame. Actually, any info 
field length up to 2000 bytes may be 
specified for use between agreeing 
packeteers if a reliable path is available. 
Now, press E to commence the LO-MEM 
multi-frame transmit function. 


In Now connected mode, the program 


3.93 


will calculate the number of frames to be 
transmitted, divide them by the number of 
frames per packet specified, calculate the 
total number of packets to be transmitted, 
calculate the number of frames in the last 
packet, and calculate the number of bytes 
in the last frame of the last packet. It 
will then begin sending them automatically. 
While they are being transmitted, the top 
line of video will display the remaining 
number of frames to be transmitted, and up 
to the first 15 lines of the packet being 
sent. 


After the packet is transmitted, the 
program will switch to the receive mode and 
display <OK> if the acknowledgment was 
correctly received, or <RESENDING> if it 
was not received correctly or the T1 resend 
timer times out. Assuming that the ACK was 
correctly received, it will then assemble 


and transmit the next packet. The total 
assembly time for each multi-frame packet 
including CRCting each frame, is measured 


in milliseconds. This process will 
continue automatically till all LO-MEM data 
has been transmitted and acknowledged. 


in: ‘thee NOt connected mode, the 
operation is almost identical to that just 
described, except the operator must press 
the E key from the main menu to sequence 
and then transmit each packet till all 
LO-MEM has been transmitted, as ACK's will 
obviously not be received. This function 
is seldom if ever used in the NOT connected 
mode and was included only to satiate one 
of our rather unigue BETA testers who gets 
his jollies from sending long multi-frame 
packets in this mode. 


Figure 5 is the commented source code 


tor the multi-frame transmit mode 
subroutine. It is easy to follow when one 
understands how the regular registers, 
alternate registers, and stack are _ used 


from SEND7 onward. 


REGULAR REGISTERS: 


A = parallel byte from memory 
Bc= time delay routine in §SN1 
D = parallel byte value in SN1 
E = bits per byte counter SN1 
HL = JP (HL) countdown jump SN1 
IX = unused 

IY = xmit byte memory location 


ALTERNATE REGISTERS: 


A = unused 

B = frames in the current packet 
C = last frame last pack pointer 
DE = last frame last packet length 
HL = frame length except for last 


STACK IN SEND7: 
Bytes remaining to send in frame 


The SEND7 subroutine in Figure 5 is 
not really a sticky wicket if one realizes 
that the program always sets alternate C 
register to lmore than B register, except 
for the last packet being transmitted from 
LO-MEM. As such, it never jumps to KYBD4B 


3.94 


except for the last frame of the last 
packet. For the last multi-frame packet 
only, alternate C and alternate B are set 
to one less than the number of frames to 
transmit in this final packet. When the 
next to last frame of this last packet has 
been transmitted, alternate C is 
decremented to zero, so jumps off to KYBD4B 
that pushes alternate DE on the stack which 
is the length of the final frame of the 
last packet. 


The SN1 and SN1A subroutines in Figure 
5 do the yeoman job of converting the 
parallel decimal byte to the synchronous 
1200 baud serial bit that is output via 
port zero. SNIA is used for 126 decimal 
flags that do not utilize zero-insertion, 
and SN1 is. called for data bytes between 
flags that may require zero-insertion. 


E. DISK I/O FROM WITHIN PACKET PROGRAM: 


At first glance appears as easy as 
falling off a log. Always be suspicious of 
easy logs in this game. On second glance, 
when one realizes that virtually all of RAM 
memory from 17408 to 28672 is used by the 
TRS-80 for disk subroutines, and this is 
the area where the software approach stores 
long data from the keyboard or disk to be 
transmitted in multi-frame packets, it 
becomes apparent that both the packet data 
and disk subroutines cannot occupy the same 
memory at the same time. 


One simple solution is to leave the 
packet program, do the disk I/O functions 


desired, return to the packet program, 
clear out low memory, and resume 
packeteerina. Though simple and easy to 


decided inconvenience 


accomplish, Pe aS: a 
approach for the 


and time consuming 
operator. 


What we desired was having our cake 
and eating it too; i.e., having the write 
to disk and read from disk functions within 
the software approach program, while at 
almost the same time being able to use low 
memory for storing long data to be 
transmitted in multi-frame packets. 


The solution to this apparent paradox 
was to save the TRS-80's minimum disk 
operating system (system 1) in mid-memory 
and write our own disk I/O subroutine that 
this section delineates. Our disk I/O 
subroutine requires only 1859 bytes of 
memory and serves three purposes: 


1. Volume 2 is a teaching textbook as well 
as a working AX.25 program. As such, it 
familiarizes the reader with writing 
direct disk I/O subroutines. 

2, Allows disk I/O without leaving the 
packet program. 

3. Provides the basis for Volume 3's auto- 
matic-unattended disk access by another 
packet station. In essence, it is a 
mini-version of a computer bulletin 
board system with the SEND, SAVE, LIST, 


and HELP commands sent via packet. 


Figure 2% SHIFT menu illustrates the 
3 commands used for the disk I/O functions 
from within the software approach program. 
Shift R loads a disk file of up to 12K 


bytes in length to high memory (53248 up) 
and shift D moves it low memory tor 
multi-frame packet transmission. SHLEE. Oo 


saves up to 12K bytes of high memory in a 
disk file of whatever name the operator 
wishes to give it. The high memory data 
may be either input from the keyboard using 
the edit/modify mode, or conversely may be 
received packets the operator wishes to 
save on disk. 


Figure 6 is the commented source code 
for this subroutine which is largely 
self-explanatory. It works quite well with 
the Model I TRS=80 and on a maybe basis for 


the Model III TRS-80 depending upon which 
version of ROM the user's” system has 
installed. 


F. REAL-TIME EDIT/MODIFY/MONITOR MODE 
FOR COMPUTER NETWORKING _ PROGRAMS: 


Whether the software or hardware 
approach to packet radio is used, we have 


found that an in-program (within the 
terminal interface program TIP) subroutine 
that allows instant access to the 
computer's 64K bytes of memory, 1024 bytes 


per page displayed on video, is a useful 
adjunct to the packet operator% tool kit. 


Memory may be reviewed in the edit 
mode and modified in the modify mode if 
desired. If the operator wishes to save 
the*modified TIP it may be dumped to disk 
thus eliminating the time consuming 
requirement of exiting the TIP program, 


loading the TIP source code into an 
Editor/Assembler, modifying the source 
code, assembling the program, and then 


writing it on disk. 


In addition to the edit/modify/monitor 
functions, this subroutine serves as’ the 
keyboard input subroutine for typing packet 
messages into low memory beginning at 
17408. Up to 12 pages, 1024 bytes per 
page, may be used by enthusiastic typists. 
A carriage return followed by a line feed 
is input by pressing ENTER, End of message 
delimiters, 128 decimal, are input by 
pressing shift zero. 


The short 866 byte subroutine that 
performs the edit/modify mode functions is 
illustrated in Figure 7 which is the 
commented source code. 


The edit/modify program may be 
considered a subroutine if you wish, but it 
is truly a stand alone program that may be 
appended to any variety of software where 
the user wishes to access to all 64K bvtes 
of memory WITHOUT leaving the program. 
Depending on the ROM/RAM varieties in the 
particular computer, the user may not onlv 


review, but actively modity anywhere from 
48K to 64K of memory while the program is 
up and running. 

EDIT/MODIFY PROGRAM ENTRY POINTS: 


There are 3 entry points to save the 
user the trouble of having to page too far 
through memory. They may be called from 
the TIP program's main menu in Figure 2 
by: 


l. Press M to go to the 1024 byte page 
of beginning in mid-memory at 40960 
decimal. 

2. Pressing SHIFT M from the menu will 
display-the 1024 byte memory page 
beginning at 53248 in high memory. 

3. SHIFT L from the menu will display 
the 1024 byte memory page beginning 
at 17408 in low memory. 


We will assume you pressed M from the 
TIP menu which takes us to memory location 
38912 that is in line 5240 of Figure 7's 
source code program. Had you pressed SHIFT 
M or SHIFT L, then the HL register would 
have been loaded with 53248 or 17405, 
respectively and the jump made to 38915 in 
MEM that is in line 5250. 


The rest of the subroutine in Figure 
7's commented source code is largely 
self-explanatory. 


The edit/modify/monitor in-program 
subroutine is a_euseful tool for the 
packeteer. LES ats elegant in its 
Simplicity, yet a very POWERFUL tool. By 
all means modify it to suit your own 


operating habits and _ fancy. If you are 
used to using memory modifier and/or 
monitor programs such as SUPERZAP, DEBUG, 


ZAPSIT, etc., you may abandon them for this 
short in-program subroutine once you become 


accustomed to using it. 


A new version of the edit/modify 
subroutine using a number of the Electric 
Pencil (tm) word processing program 
commands for keyboard input of packet 
messages may be implemented later this 
year. 

CONCLUSION: 


First, a personal note. Writing the 
"software approach' for both Volumes 1 and 
2 was great fun and very gratifying. 


why? 


Because so many experienced packeteers 
told us it could not be done using a 
modestly priced 2 MHz ballpark crystal 
clock Model als or Model III TRS-80 
microcomputer. Actually, most any computer 
with a 1 MHz or faster clock should be able 


to handle 1200 baud synchronous packet 
using the software approach. The Model I 
or Model III TRS-80 is quite capable of 


running 2400 baud packet using this program 
if the timing constants are carefully 
trimmed and adjusted. 
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With the new Zilog Z-800 micro=- 
processor and its extremely fast clock, 
(and internal cache memory), the software 
approach may be extended to 9600 baud and 
well beyond. 


Want to dig deeper? If so, try Volume 
1 or 20f 'Synchronous Packet Radio Using 
The Software Approach.' 


Vol. 1 = Vancouver Protocol is $22 ppd 
and Vol. 2 = AX.25 Protocol also $22 ppd. 
If you want the programs on disk in 
addition to the book which is required for 
instructions to personalize the disk, 
specify Model I or Model III TRS-80. The 
disk programs are an additional $29 ppd. 
Uses. phone orders are welcome during 
business hours at (716)-753-2654 or you may 
order from: 


Richcraft Engineering Ltd. 
#1 Wahmeda Industrial Park 
Chautauqua, New York 14722 


Do not want to dig deeper? Then we 
highly recommend to you the Tucson Amateur 
Packet Radio terminal node controller. It 
is a highly efficient, very professional, 
and first-rate kit. It is available for 
$252 which is about one half the price were 
it produced by a profit making enterprise 
that most likely would not do as thorough a 
job as TAPR. 


We salute TAPR and all those who have 
contributed to the development of its TNC, 
for an outstanding service to amateur 
radio. 
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CHANGE REPEATER CALL LYRS 
CLEAR NON-PGM MEM 17K-62K 
ABORT LOW<-MEM PAK SEQUENCE 
SHIFT MENU 

SEND WAIT RECUEST (RNR) 
(not shown) : 

DISCONNECTED MODE 


mM we kX GNOOZRHAHAOQPY 


tetas 1 bit time --"---> 
833.333 microseconds 
Pp 
R 
1@) 
Cc 
E 
Ss 
Ss 
tyvme3 tyme4 tyme 1 tyme2 


delay delay ao delay delay delay 


"x? 23 23 


ENTER OPTION DESIRED ? 


W2EUP CONNECT REQUEST CO 
W2EUP DISCONNECT REQUEST 
W2EUP CONNECT ACKNOWLEDGE 
THIS IS AX.25 PROTOCOL 
AUTO CONNECT TOGGLE OFF 
W2EUP = GIL BOELKE MESSAGE 
SET INFO FIELD LOMEM PACKS 
QUICK BROWN FOX MESSAGE 
SET OPENING FLAG LENGTH 
INPUT/XMIT NORMAL INFO = V 
INPUT/XMIT UNNUMB INFO = V 
NOT CONWEK TCO OWil STATION 
SET RE-TRY IN CONNECT MODE 
SEND CLEAR WAIT (RR) 

(not shown): 

FRMR FRAME REJECT 


SHIFT MENU 3 


XMIT 40960 Up CONTINUOUSLY 
LOAD MID-ME": ASCII UUUUUU 
EDIT/MODIFY INSTRUCTIONS 
TRANSMIT EXTERNALLY ONLY 
SEND MORSE: I.D. 
CAUTION ¥** REETORE DOS ** 
DISPLAY RECYV PACKS @ 53248 
OSCAR LO: -CALL/EANCLE List 
SAVE HI-MEM OIJ DISK 
TRANSMIT BAUD RATE SELFCT 
CLEAR HI=MEMORY 53248 + 
RECEIVE AX.25 PROTOCOL 
NORMAL DISPLAY = NOT DPLL 
NOTE: 


BOOT DOS READY 

MOVE HI-MEM TO LOW-MEMOPY 
CHANGE RECEIVE DPLL EASE # 
TRANSMIT TO HI-eMEMORY ONLY 
SEND SEQUENTIAL ACkS 
DISPLAY LOW MEMORY @ 17403 
RESTORE PROGPAM POINTERS 
MOVE PROGRAM TO LOW MEMORY 
LOAD. DISK: FILE TO nIsrnA 
TEST OTHER ‘STATION STATUS 
SEND MORSE FROM DLEYEBOARD 
RECV VANCOUVER NOT CONNEC? 
DISPLAY DPLL LAST QUADRAHUT 


SPACE BAR IN RECEIVE MODE = KESLND LAST PACK 


lown tl 
BNOK DH wy Ue Pr Um AoW 


oe oe | | || 


fon) 


ee | | | | 


aAnwvanantow 


tou i 


NX 


00100 
00110 
00120 
00130 
00140 
00150 
00160 
00170 
00180 
00190 
00200 
00210 
00220 
00230 
00240 
00250 
00260 
00270 
00280 
00290 
00300 
00310 
00320 
00330 
00340 
00350 
00360 
00370 
00380 
00390 
00400 
00410 
00420 
00430 
00440 
00450 
00460 
00470 
00480 
00490 
00500 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00580 
00590 
00600 
00610 
00620 
00630 
00640 
00650 
00660 
00670 
00680 


=e 


oe 
| | | 


me Ki 
KOS 
it 


we we Se we TE ME we ae NO ME ne we 


=e 


=e NO 


: THIS SUBROUTINE IS ENTERED IN LINE 440, 
3 DEPEN 


; MAIN 


: THE SOFTWARE DIGITAL PHASE LUCKED LOOP 
; END OF THIS SUBROUTINE IN LINES 1880 = 2230, 


LINE 900 ON ARE: 


FIGURE 3 


RECEIVE MODE REAL-TIME SDLC/HDLC SERIAL SYNCHRONOUS 
DATA STREAM TO PARALLEL DECIMAL BYTE CONVERSION. 


THE REGISTERS USED IN THIS RECEIVE MODE SUBROUTINE FROW 
REGULAR REGISTERS 


USED + NEW PORT ZERO VALUE IN EACH DPLL QUADRANT 
USED THROUGHOUT 


DPLL CO 


yy 
UNT 


DOWN VALUE FOR FIRST 3 DPLL QUADRANTS 
8 BITS PER BYTE COUNTER 


CALCULATED DPLL CQUNTDOWN VALUE FOR 4TH QUADRANT 


LAST PORT ZERO VALUE 

MEM LOCATION TO STORE ENDING FLAG ADDRESS 

ONLY FOR EQUALIZING TIME DELAYS; INC IX & DEC IX 
UNUSED 


UNUSED 
UNUSED 
RECEIVED 


ALTERNATE REGISTERS 


PARALLEL BYTE WITH ZERO-DELETION 


RECEIVED PARALLEL BYTE WITHOUT ZERO-DELETION 
INCOMING BIT VALUE AT CENTER OF BIT TIME FRAME 
LAST BIT VALUE. AT CENTER OF BIT TIME. B’RAME 

: HL= MEM LOCATION TO STORE CONVERTED DECIMAL BYTE 


MENU, 


490, 0R 500 


DING ON WHETHRR RECEIVE MODE IS ENTERED FROM THE 
NOT CONNECTED MODE, 


OR NOW CONNECTED MODE. 


(DPLL) IS AT THE 


3 SIGNIFICANT RECEIVE MODE SUBROUTINES FROM VOLUME 2 


MODE 


MODF.1 
MODEI1A 


BEFOR1 


LD 
CALL 
LD 
CP 
JP 
CALL 
CALL 
LD 
CP 
CALL 
LD 
CP 
CALL 
LD 
cP 
JP 
LD 
CP 
CALL 
EXX 
LD 
LD 
LD 
EXX 
CALL 


BC, 6500 
060H 

A, (14400) 
2 

Z,MODE 
RESKCV 
TESTSP 

A, (SIGN7) 


Z,CNRO 
A, (SIGN6) 
1 


Z,SETIT 

A, (SIGNS) 
1 
Z,SPACK~10 
A, (SIGN4) 


Z,DISCAK 
HL, 40959 
DE,0 
BC ,0 


CLRMUL 


7.01 SECOND DEBOUNCE 
sTIME DELAY SINCE THE 
;CLFAR KEY IS USED TO 
?;TOGGLE BETWEEN THE MENU 
3;AND RECEIVE MODE, 
2RESTORE RECEIVE VIDEO 
sTEST SP FOR PGM ERRORS 
s;DISPLAY ON VIDEO 

:THAT A CONNECTION 

s ACKNOWLEDGE WAS SENT. 

i; IF LONG DATA FROM LOMEM, 
UP TO 12288 BYTES, THEN 
RESET POINTERS. 

;IF AX.25 STATUS REQUEST, 
;THEN DELAY 1 SECOND 
;BEFORE SENDING RR/RNR. 
sDISPLAY ON VIDEO 

;THAT <DISCCNNECT ACK> 
:WAS TRANSMITTED. 

¢ SWAP ALTERNATE REGISTERS 
;MIDMEM TO STGRE PACKET 

s INITIALIZE AT ZERO 

s INITIALIZE AT ZERO 
sRESTORE REG. REGISTERS 
CLEAR CLOSING FLAG STORE 


86'e 


00690 NEWONE 


00700 
00710 
00720 
00730 
00740 
00750 
00760 
00770 
00780 
00790 
00800 
00810 
00820 
00830 
00840 
00850 
00860 
00870 
00880 
00890 
00900 
00910 
00920 
00930 
00940 
00950 
00960 
00970 
00980 
00990 
01000 
01010 
01020 
01030 
01040 
01050 
01060 
01070 
01080 
01090 
01100 
01110 
01120 
01130 
01140 
01150 
01160 
01170 
01180 
01190 
01200 
01210 
01220 
01230 
01240 
01250 
01260 
01270 


FLG1 


FLG2 


A, (AUT) 
i 
Z,TIMOUT 
A, (RTRY) 
1 
Z,TESTRY 
A, (0) 


D 
Z,NEWONE 
0,A 

Z, NEWONE 
HL, STORE 
A, (DVAL) 


Z,BEFOR1 


D,A 
E 


E,D 

Cc 

A,Cc 

126 
Z,FLG2+31 
FLG1 

0,A 
Z,BEFOR1 
D,A 

E 

E,D 


LG2+41 


ese *%* Ne 
waa 


O PNEPN OW 


NZ ,FLG2+35 


IN1A+1 


gAUTOMATIC CONNECT MODE ? 
;IF SO, AND CONNECTED, T2 
sTIMES OUT 6 1/2 MINUTES. 
g:IN RE=-TRY CONDITION ? 
s;THEN ACTUATE T1 RE-TRY 
sTIMER BEFORE RESENDING. 
3EX-2211 OUTPUT PORT ZERO 
;SAVE IT IN 'D' REGISTER 
sKEYBOARD PSUEDO MEMORY 
s;CLEAR KEY PRESSED ? 

;IF SO, GOTO MAIN MENU 
SPACE BAR PRESSED ? 

siIF SO, MANUAL RESEND. 
sEX-2211 OUTPUT PORT ZERO 
sANY CHANGE SINCE LAST ? 
3 IF NOT, GO LOOK AGAIN 
3DCD CARRIER DETECT ? 

3;NO 1200/2200 TONES 

sEND FLAG ADDRESS STORE 
sDPLL COUNTDOWN VALUE 
3;START OFF WITH NOMINAL 
sSOFTWARE DPLL LINE 1880 
sEQUALIZING TIME DELAY 
sEQUALIZING TIME DELAY 
sEQUALIZING TIME DELAY 
EQUALIZING TIME DELAY 
*DCD CARRIER DROPPED ? 
sTHEN START OVER AGAIN 
3SWAP ALTERNATE REGISTERS 
3SAVE INCOMING BIT IN ‘'D* 
sCOMPARE WITH LAST ONE 
;DATA IN BIT 7 

s;UPDATE E FOR NEXT ONE 
SHIFT INTO CARRY 
zINCOMING BIT PATTERN 
3SWAP FOR COMPARE 

sFOUND AN OPENING FLAG ? 
;IF SO, GOTO LINE 1280 
ELSE GO BACK TO FLG1 
3START LOOKING AGAIN. 
7DCD CARRIER DROPPED ? 
sTHEN START OVER AGAIN 
SWAP ALTERNATE REGISTERS 
3 INCOMING BIT VALUE TO D 
sCOMPARE WITH LAST ONE 
UPDATE E FOR NEXT TIME 
sDATA IN BIT 7 

sSHIFT INTO CARRY 

INPUT DATA = 
ACCUMULATES HERE. 

sg INCOMING BIT PATTERN 
TEST IT 

FOR ANOTHER OPENING FLAG 
3;IF SO, JUMP TO LINE 1330 
BUILT UP DATA VALUE 
sRESTORE REG, REGISTERS 
¢DECREMENT BIT COUNTER 
sNOT ZERO, GET NEXT BIT 
31ST FRAME DATA GOTO 1600 


01280 
01290 
01300 
01310 
01320 
01330 
01340 
01350 
01360 
01370 
01380 
01390 
01400 
01410 
01420 
01430 
01440 
01450 
01460 
01470 
01480 
01490 
01500 
01510 
01520 
01530 
01540 
01550 
01560 
01570 
01580 
01590 
01600 
01610 
01620 
01630 
01640 
01650 
01660 
01670 
01680 
01690 
01700 
01710 
01720 
01730 
01740 
01750 
01760 
01770 
01780 
01790 
01800 
01810 
01820 
01830 
01840 
01850 
01860 


IN1 


INIA 


IN2 


I NS 


IN4 


FL1 


DELETE 


Z,MOVEM+1 
D,A 

E 

E,D 


B 


Cc 

A,C 

126 
Z,FL1 
254 
Z,MOVEM 
254 

124 

Z, DELETE 
A,B 


Cc 
NZ, IN4 


Z,MOVEM=3 


A,144 


H 
Z,MOVEM+1 
IN3+1 

B 


(IX) 
(IX) 
TYME 


;STUFF 1ST FLAG HERE 
RESTORE REG. REGISTERS 
RESET BIT/BYTE COUNTER 
;DIGITAL PHASE LOCK LOOP 
7GO LOOK AGAIN 
sEQUALIZING TIME DEALY 
sEQUALIZING TIME DELAY 
3GO LOOK FOR NEXT BYTE 
PACKET TONES DROPPED ? 
IF SO, PROCESS IT, 
3;SWAP ALTERNATE REGISTERS 
zs INCOMING BIT VALUE TO D 
sCOMPARE WITH LAST ONE 
sUPDATE E FOR NEXT TIME 
3;DATA IN BIT 7 

#SHIFT INTO CARRY 

3INPUT DATA BITS e@ 
sACCUMULATES HERE. 
sINCOMING BIT PATTERN 
TEST IT 

FOR A CLOSING FLAG ? 
;IF SO, GOTO LINE 760 
PACKET TONES DROPPED ? 
¢ IF SO, PROCESS IT 
:REMOVE BIT ZERO 
70111110X PATTERN ? 

3IF SO, DO ZERO DELETION 
:BUILT UP DATA VALUE 
RESTORE REG. REGISTERS 
sDECREMENT BIT COUNTER 
;NOT ZERO, GET NEXT BIT 
s;SAVED FOR DPLL TESTING 
3:SWAP ALTERNATE REGISTERS 
:BYTE STASH MEM LOCATION 
3STASH IT IN MEMORY 

3TOO LONG A PACKET ? 
:OVER 4096 BYTES LONG ? 
3;IF SO, PROCESS IT 
RESTORE REG. REGISTERS 
RESET BITS/BYTE COUNTER 
:DIGITAL PHASE LOCK LOOP 
sCONVERT INCOMING BIT 
;GOT A CLOSING FLAG 
sRESTORE REG. REGISTERS 
sFLAG LOCATION MINUS ONE 
#FLAG MEM LOCATION 

3;STORE FLAG ADDRESS LSB 
3;NEXT STORE LOCATION 
3STORE FLAG ADDRESS MSB 
:NEXT STORE LOCATION 
OUT OF BOUNDS DUE TO = 
;RUN AWAY TNC ? 

IF SO, PROCESS IT 

ELSE GO FOR NEXT ONE 
3ZERO DELETION, SO @ 
:BACKUP ALTERNATE B 
sEQUALIZING 

sTIME DELAY. 

sDIGITAL PHASE LOCK LOOP 


66°E 


01870 JP IN1 sCONVERT NEXT BIT 00100 ; FIGURE 4 
01880 TYME LD A, (14400) sESCAPE IS CLEAR KEY 00110 
01890 cp 2 sIF PRESSED GOTO = 00120 ; IBM SDLC CRC GENERATION AND CRC CHECKING SUBROUTINES 
01900 JP Z,MENUO-1 *MAIN MENU FOR INSTRUCTS. 00130 
01910 LD B,23 MODEL I COUNTDOWN VALUE 00140 ; CRC1 AND CRC2 ARE FOR GENERATING THE 2 BYTE CRC VALUE 
01920 TYME1 DJN2 TYME1 1ST QUADRANT COUNTDOWN 00150 ; FOR A FRAME OF (LENG1) BYTES IN LENGTH. ADDREZ IS THE 
01930 IN A, (0) sPORT ZERO VALUE TO 'A' 00160 ; MEMORY LOCATION OF THE BEGINNING OF THE SINGLE FRAME 
01940 CP E sANY CHANGE FROM LAST ? 00170 ; PACKET TO BE TRANSMITTED. MULTI-FRAME PACKETS USE A 
01950 JP NZ ,DEC2 :IF SO, GOTO LINE 2120 00180 ; VARIABLE ADDREZ DEPENDING UPON WHERE EACH FRAME HAS 
01960 LD B,23 ;MODEL I COUNDOWN VALUE 00190 ; BEEN SEQUENTIALLY MOVED IN MEMORY STARTING AT 43008. 
01970 TYME2 DINZ TYME2 32ND QUADRANT COUNTDOWN 00200 
01980 IN A, (0) sPORT ZERO VALUE TO 'A' 00210 ; RCRC BEGINNING IN LINE 870 TESTS THE RECEIVED CRC VALUE 
01990 cP E zANY CHANGE FROM LAST ? 00220 ; OF a FRAME STARTING at (BGINIT) IN MEmory wITH aA TOTAL 
02000 JP NZ,DEC1 zIF SO, GOTO LINE 2150 00230 ; LENGTH OF "BC REGISTER BYTES. MULTI-FRAME PACKETS OF 
02010 LD B,23 MODEL I COUNTDOWN VALUE 00240 ; 1 TO 7 FRAMES/PACKET ARE SEQUENTIALLY ACCOMODATED. 
02020 TYME3 DJNZ TYME3 33RD QUADRANT COUNTDOWN 00250 
02030 IN a, (0) :PORT ZERO VALUE TO 'A' 00260 ; TABLE BEGINNING ON PAGE THREE IS THE LOOK-UP TABLE FOR 
02040 CP E sANY CHANGE FROM LAST ? 00270 ; THE BRILLIANT 'BYTE WISE' CRC SUBROUTINE SUGGESTED BY 
02050 JP NZ,INC1 sIF SO, GOTO LINE 2180 00280 ; ARAM PEREZ IN THE THE JUNE '83 ISSUE OF I.E.E.E. MICRO. 
02060 LD B,D sADJUSTED COUNTDOWN VALUE 00290 ; THE TABLE VALUES FOR THE IBM SDLC 'CRC' WERE GENERATED 
02070 TYME4 DINZ TYME4 ¢ 4TH QUADRANT COUNTDOWN 00300 ; BY W4UCH AS THE PEREZ PAPER ONLY GAVE THE CRC16 VALUES. 
02080 IN A, (0) :PORT ZERO VALUE TO 'A' 00310 
02090 cP E sANY CHANGE FROM LAST ? 00320 CRCVAL DEFW 0 :RECEIVE CRC VALUE STASH 
02100 JP NZ,INC2 ;IF SO, GOTO LINE 2210 00330 ENDCRC DEFW 0 :XMIT CRC VALUE STASH 
02110 RET :DPLL DONE. GO PROCESS IT 00340 CRC1 LD HL, ADDRE Z BEGIN MESSAGE LOCATION 
02120 DEC2 LD E,A ;SAVE NEW BIT IN ‘ES 00350 LD BC, (LENG1) ;LENGTH OF FRAME IN BYTES 
02130 LD D,15 sWAY TOO LATE, SO SHORTEN 00360 LD DE, 65535 sINTIALIZE DIVIDEND 1'S 
02140 JP TYME2—-2 2LAST QUAD COUNT A BUNCH. 00370 CALL CRCT s;GENERATE CRC LINE 490 
02150 DEC1 TD E,A sSAVE NEW BIT IN 'E! 00380 CALL FINCRC 3;SORT/STUFF RIGHT ORDER 
02160 LD D,20 *TINY BIT TOO LATE, SO 00390 LD A, (SIGN2) DISPLAY CRC VALUE = 
02170 JP TYME3-2 :SHORTEN LAST QUAD A BIT. 00400 CP 1 ;ON VIDEO DISPLAY ? 
02180 INC1 LD E,A ;SAVE NEW BIT IN ‘E' 00410 RET Z :IF NOT, RETURN. 
02200 JP TYME4=2 LENGTHEN LAST QUAD A BIT 00430 CALL DZ 3;ON TOP LINE OF VIDEO. 
02210 INC2 LD E,A sSAVE NEW BIT IN ‘ES 00440 CRC2 LD BC ,960 »= 15 LINES OF VIDEO 
02220 LD D,29 ;WAY TOO SOON, LENGTHEN 00450 LD HL, ADDRE 2Z BEGIN PACKET ADDRESS 
02230 RET :LAST QUADRANT A BUNCH. 00460 LD DE, 15424 32ND LINE OF VIDEO 
02240 ;---+------ spc Fas Mae ae ena ere ee ee 00470 LDIR ;DISPLAY MESSAGE SENT 
02250 : END OF SYNCHRONOUS BIT TO PARALLEL BYTE CONVERSION VOL 2 00480 RET sRETURN WHENCE U CAME +1 
, 00490 CRCT LD a, (HL) ;FIRST BYTE TO CRC 
00500 INC HL s INCREMENT FOR NEXT ONE 
00510 PUSH BC SAVE BYTES TO CRC 
00520 PUSH HL SAVE NEXT BYTE LOCATION 
00530 XOR E 7XOR REMAINDER LSB W/'A! 
00540 LD C,A ;SAVE RESULT IN 'C' 
00550 LD B,0 ?ZERO OUT 'B! 
00570 ADD HL,BC ;ADD BC TO LOCATION 
00580 ADD HL, BC ADD BC TO LOCATION 
00590 LD A,D :REMAINDER MSB TO 'A' 
00600 XOR (HL) 3XOR WITH TABLE VALUE 
00610 LD E,A ?SAVE RESULT IN 'E! 
00620 INC HL ;NEXT TABLE LOCATION 
00630 LD D, (HL) :SAVE VALUE IN ‘'D! 
00640 POP HL :NEXT BYTE TO CRC MEM 
00650 POP BC s;NUMBER BYTES TO CRC 
00660 DEC BC 7LESS ONE 
00670 LD A,B ;TEST FOR 
00680 OR eC 3 ZERO 


OOL’e 


00690 
00700 
00710 FINCRC 
00720 
00730 
00740 
00750 
00760 
00770 
00780 
00790 
00800 
00810 
00820 
00830 


00850 
00860 
00870 
00880 
00890 
00900 
00910 
00920 
00930 
00940 
00950 BADCRC 
00960 

00970 

009 80 

00990 


RCRC 


JP 
RET 
LD 
CPL 
LD 
LD 
LD 
INC 
LD 
CPL 
LD 
LD 
RET 


3 F 
e 

00840 3 CALLED WITH 
; NUMBER OF BYTES IN THE FRAME 


NZ,CRCT 
A,E 


HL, (WHER4B) 
(HL) ,A 
(ENDCRC+1),A 
HL 

A,D 


(HL) ,A 
(ENDCRC) ,A 


OLLOWING IS RECEIVE CRC CHECK FOR EACH FRAME. 
'BC' REGISTER ALREADY HAVING THE TOTAL 


DE, 65535 

HL, (BGINIT) 
CRCT 
(CRCVAL) ,DE 
HL,61624 
18H 

NZ, BADCRC 


AF 
AF 
IY,37692 
SHOWIT 
MODE1A 


CRC LOOKUP 


3I1F NOT, CRC NEXT ONE 
;ELSE ALL DONE. RETURN 
sDE = CRC 2 BYTE VALUE 
sCOMPLEMENT IT 

:END OF MESSAGE +1 

LD 1ST CRC ON MESSAGE 
sAND SAVE IT HERE 
sNEXT MESSAGE LOCATION 
3;SECOND CRC BYTE 
sCOMPLEMENT IT 

?LD 2ND CRC ON MESSAGE 
sAND SAVE IT HERE 
;RETURN WHENCE U CAME +1 


IT IS 


(INCLUDING CRC BYTES). 


RECEIVE CRC CHECK 
BEGIN FRAME LOCATION 
:CPC ALL INCLUDING CRC 
*SAVE REMAINDER IN MEM 
sCOMPARE REMAINDER WITH 
361624 DECIMAL 

sNOT ZERO = BAD ONE 

3 OK, SO RETURN 
sADJUST STACK 

sFOR 2 CALLS 

:<BAD CRC> MESSAGE 
sDISPLAY ON VIDEO 

3GO AWAIT NEXT PACKET 


=“ 
B™=OSCOYNOACAW DL wt 
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OnAADNUORWON 


NJ BO DO 
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wW 
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FIGURE 4 CONTINUED 


This is the 512 byte CRC lookup table printed out as 256 two 
The label TABLE is at location 1, 


byte words to save space. 


DEFW 0 53 DEFW30631 
DEFW 4489 54 DEFW 26158 
DEFW 8978 55 DEFW 21685 
DEFW 12955 56 DEFW 17724 
DEFW 17956 57 DEFW 48587 
DEFW 22445 58 DEFW 44098 
DEFW 25910 59 DEFW 40665 
DEFW 29887 60 DIF 36688 
DEFW 35912 61 DEFW 64495 
DEFW 40385 62 DEFW 60006 
DEFW 44890 63 DEFW 55549 
DEFW 48851 64 DEFW 51572 
DEFW 51820 65 DEFW 16900 
DEPW 56293 66 DEFW 21389 
DEFW 59774 67 DEFW 24854 
DEFW 63735 68 DEFW 28831 
DEFW 4225 69 DEFW 1056 
DEFW 264 70 DEFW 5545 
DEFW 13203 71 DEFW 10034 
DEFW 8730 72 DFW 14011 
DEFW 22181 73 DEFW 52812 
DEFW 18220 74 DEFW 57285 
DEFW 30135 75 DEFW 60766 
DEFW 25662 76 DEFW 64727 
DEFW 40137 77 DEFW 34920 
DEFW 36160 78 DEFW 39393 
DEFW 49115 79 DEFW 43898 
DEFW 44626 80 DEFW 47859 
DEFW 56045 81 DEFW 21125 
DEFW 52068 82 DEFW 17164 
DEFW 63999 83 DEFW 29079 
DEFW 59510 84 DEFW 24606 
DEFW 8450 85 DEFW 5281 
DEFW 12427 86 DEFW 1320 
DEFW 528 87 DEFW 14259 
DEFW 5017 #488 DEFW 9786 
DEFW 26406 89 DEFW 57037 
DEFW 30383 90 DEFW 53060 
DEFW 17460 91 DEFW 64991 
DEFW 21949 92 NEFW 60502 
DEFW 44362 93 DEFW 39145 
DEFW 48323 94 DFEFW 35168 
DEFW 36440 95 DEFW 48123 
DEFW 40913 96 DEFW 43634 
DEFW 60270 97 DEFW 25350 
DEFW 64231 98 DEFW 29327 
DEFW 51324 99 DEFW 16404 
DEFW 55797 100 DEFW 20893 
DEFW 12675 101 DEFW 9506 
DEFW 8202 102 DCFW 13483 
DEFW 4753 103 DEFW 1584 
DEFW 792 104 DEFW 6073 


105 
106 
107 
108 
109 
110 
111 
112 
ii3 
114 
115 
116 
117 
118 
119 
120 
121 
122 
123 
124 
125 
126 
127 
128 
129 
130 
131 
132 
133 
134 
135 
136 
137 
138 
139 
140 
141 

142 
143 
144 
145 
146 
147 

148 

149 
150 

ibeg 

152 

133 

154 

155 

156 


DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 

DEFW 

DEFW 
DEFW 
DEFW 
DEFW 
DEFW 

DEFW 

DEFW 
DEFW 

DEFW 

DEFW 

DEFW 

DEFW 

DEFW 

DEFW 


61262 
60223 
52316 
56789 
43370 
47331 
35448 
399211. 
Zoo SD 
Zak O2 
20629 
16668 
Lot L 
92:58 
5809 
1848 
65487 
60998 
56541 
52564 
47595 
43106 
39673 
35696 
33800 
38273 
42778 
46739 
49708 
54181 
57662 
61623 
2112 
6601 
11090 
15067 
20068 
24557 
28022 
31999 
38025 
34048 
47003 
42514 
53933 
49956 
61887 
57398 
633.7 
2376 
L315 
10842 


LO? 
158 
159 
160 
167 
162 
163 
164 
165 


DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEPW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 
DEFW 


24293 
20332 
32247 
27774 
42250 
46211 
34328 
38801 
58158 
62119 
49212 
53685 
10562 
14539 
2640 

7129 
28518 
32495 
Loo TZ 
24061 
46475 
41986 
38553 
34576 
62383 
57894 
53437 
49460 
14787 
10314 

6865 

2904 
32743 
28270 
23197 
19836 
50700 
koa ig 
58654 
62615 
32808 
37281 
41786 
45747 
19012 
23501 
26966 
30943 
3168 

7657 
12146 
LELZ3 


209 
210 
211 
212 
23 


54925 
50948 


1 623879 


58390 
31033 
33056 
46011 
41522 
23237 
19276 
31191 
26718 
7393 
3432 
16371 
11898 
59150 


7. 63111 


50204 
54677 
41258 
45219 
3333.6 
37809 
27462 
31439 
18516 
23035 
11618 
15595 
3696 
8185 
63375 
58886 


7 54429 


50392 
45483 
40993 
37561 
33584 
31687 
27214 
22741 
18780 
15843 
11370 

7921 

3960 


LOL E 


00100 
00110 
00120 
00130 
00140 
00150 
00160 
00170 
00180 
00190 
00200 
00210 
00220 
00230 
00240 
00250 
00260 
00270 
00280 
00290 
00300 
00310 
00320 
00330 
00340 
00350 
00360 
00370 
00380 
00390 
00400 
00410 
00420 
00430 
00440 
00450 
00460 
00470 
00480 
00490 
00500 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00580 
00590 
00600 
00610 
00620 
00630 
00640 
00650 
00660 
00670 
00680 


3 TRANSMIT SUBROUTINE: 


FIGURE 5 


SINGLE OR MULTI-FRAME 1200 BAUD 


3 PACKET WITH REAL-TIME ZERO INSERTION WHERE APPLICABLE 


SENPAK 


FLGDLY 


FLGNUM 
FLG 


FLAG 


SEND7 


KYBD4 


KYBD4A 


HL, (NORMFM) 
DE, (LASTFM) 
A, (FRMCNT) 
B,A 

A, (TESCNT) 
C,A 


IY, (STARPR) 
A,1 

(LASONE) ,A 
(SIGNG6) ,A 
A 

(ZEROMK) ,A 
(ZEROSP) ,A 
A, (BK) 

1 

Z,BAKOFF 
A, 60 


A 
Z,SEND7 


HL,98 
(SPEED) , HL 
A,126 
SNIA 


C 
Z,KYBD4A 


B 
NZ,SEND7+1 
DUN1 

DE 

SEND7+2 


sSWAP ALTERNATE REGISTERS 
sNORMAL FRAME LENGTH 
;LAST FRAME LAST PACK LEN 
:FRAMES PER PACKET 

sSAVE IN ALTERNATE 'B' 
;LAS FRM LAS PACK POINTER 
;SAVE IN ALTERNATE 'C' 
sRESTORE REG. REGISTERS 
sASSEMBLED PACK BEGIN ADR 
sLAST BIT VALUE POINTER 
:SAVE IT IN LASONE 

;SET XMIT LO-MEM POINTER 
3 ZERO OUT 

*:MARKS IN A ROW COUNTER 
;SPACES IN A ROW COUNTER 
: BACKOFF DELAY 'ON' ? 

sIF SO, DO RANDOM 
;BACKOFF AFTER CLEAR 
;NUMBER FLAGS YOU INPUT 
sMINUS 1 

sIF DONE SEND DATA IN 470 
sNUMBER FLAGS REMAINING 
3;SEND SDLC/HDLC FLAG 
RESTORE FLAG COUNTER 

;DO NEXT ONE 

:1200 BAUD COUNT NUMBER 
:STASH IT IN SPEED 

sFLAG BYTE VALUE 

;NO ZERO INSERT TRANSMIT 
;RETURN TO LINE 400 

SWAP ALTERNATE REGISTERS 
:FRAME LENGTH TO STACK 
;RESTORE REG. REGISTERS 
3;FRAME LENGTH TO 'DE' 
;DECREMENT FRAME LENGTH 
:TEST 

sFOR ZERO 

;IF ZERO, GOTO LINE 600 
:FRAME LENGTH ON STACK 
:BYTE TO TRANSMIT 

:NEXT BYTE LOCATION 

3;ZERO INSERTION TRANSMIT 
sGOTO LINE 560 

:XMIT FRAME CLOSING FLAG 
: SWAP ALTERNATE REGISTERS 
sLAST FRAME LAST PACK ? 
:IF ZERO JUMP TO LINE 670 
: DEC NORMAL FRAMES/PACK 
3;NOT ZERO, GOTO LINE 480 
:IF ZERO, GOTO LINE 690 
sLAST FRAME LAST PACK LEN 
:GOTO LINE 490 


00690 DUN1 
00700 
00710 
00720 
00730 SN1 
00740 
00750 SN2 
00760 
00770 
00780 
00790 
00800 
00810 
00820 
00830 
00840 
00850 
00860 


00870 LASTSP 


00880 
00890 
00900 
00910 
00920 
00930 
00940 
00950 
00960 SPACE 
00970 
00980 
00990 
01000 
01010 
01020 
01030 
01040 DECSP 
01050 
01060 


01070 SPACEA 


01080 
01090 
01100 
01110 
01120 
01130 
01140 
01150 
01160 


01170 SPACEB 


01180 
01190 
01200 
01210 
01220 


01230 SPACEC 


01240 
01250 
01260 
01270 


E,8 
A, (LASONE) 
1 


Z,LASTSP 
0,D 


NZ, SPACE 
0,D 
Z,MARK 


(ZEROMK) ,A 
A, (SPEED) 
HL, SPACEA 
HL 

HL, DECSP 

A 

7 

(HL) 

A, (LASONE) 
5 

Z, SPACEB 
A, (ZEROSP) 
A 
5 
Z,SPACEC 
(ZEROSP) ,A 


A,1 
(LASONE) ,A 


A,1 
(LASONE) ,A 
BC, 1 

060H 

MARK 


sSWITCH T/R RELAY 

:TO RECEIVE 

sRESTORE REG. REGISTERS 
3GOTOC RECEIVE MODE 

sBYTE VALUE TO TRANSMIT 
:NUMBER OF BITS PER BYTE 
21 = SPACE & 5 = MARK 
;WAS IT A SPACE ? 

:IF SO, GOTO LAST SPACE 
;SET Z FLAG FOR BIT ZERO 
3IF NOT ZERO SEND MARK 
;SET Z FLAG FOR BIT ZERO 
:IF ZERO SEND SPACE 

2 USEC TIMING ADJUST 
2-1 FROM BIT COUNTER 

:IF ZERO, RETURN LINE 590 
sRIGHT SHIFT ALL 1 BIT 
GO BACK FOR NEXT BIT 
sSET Z FLAG FOR BIT ZERO 
;IF NOT ZERO SEND SPACE 
sSET Z FLAG FOR BIT ZER80 
sIF ZERO SEND MARK 

32 USEC TIMING ADJUST 
g-1 FROM BIT COUNTER 

:IF ZERO, RETURN LINE 590 
sRIGHT SHIFT ALL 1 BIT 
GO BACK FOR NEXT BIT 
:SEND SPACE TONE 

:VIA PORT ZERO 

ZERO OUT ‘A' REGISTER 
sAND ZERO MARK COUNTER 
sCOUNTDOWN VALUE 

s;RETURN MEM LOCATION 
3;PUSH ON TOP OF STACK 
;JP (HL) ADDRESS 

3-1 COUNTDOWN VALUE 
;GOTO SPACEA WHEN ZERO 
JUMP TO DECSP 

PREVIOUS BIT SENT 

;WAS IT A MARK ? 

sIF “SO, ‘DON'T COUNT ZT 
:SPACE COUNTER STASH 

3$+1 TO SPACE COUNTER 

35 SPACES IN A ROW ? 

:IF SO, DO ZERO INSERTION 
3; IF NOT, SAVE NEW VALUE 
2 USEC TIMING ADJUST 
sRETURN WHENCE U CAME +1 
SINCE NOT SAME CHANGE IT 
; UPDATE LASTONE 
sEQUALIZING DELAY 
sEQUALIZING DELAY 
sEQUALIZING DELAY 
sRETURN WHENCE U CAME +1 
31 = SPACE & 5 = MARK 

; UPDATE LASTONE 

;DELAY = NO SN2 ITERATION 
; APPROX. 30 MICROSECONDS 
DO ZERO INSERTION 


cOL'é 


01280 
01290 
01300 


01310 SPACE1 


01320 
01330 
01340 
01350 
01360 
01370 
01380 


01390 DECSP1 


01400 
01410 
01420 MARK 
01430 
01440 
01450 
01460 
01470 
01480 
01490 
01500 DECMK 
01510 
01520 
01530 MARKA 
01540 
01550 
01560 
01570 
01580 
01590 
01600 
01610 
01620 
01630 MARKB 
01640 
01650 
01660 
01670 
01680 
01690 MARKC 
01700 
01710 
01720 
01730 
01740 
01750 
01760 
01770 MARK1 
01780 
01790 
01800 
01810 
01820 
01830 
01840 


0 1850 DECMK1 


01860 


A 
(ZEROMK) ,A 


(0) ,A 
(LASONE) ,A 
A 


(ZEROMK) ,A 
A, (SPEED) 
HL,DECSP 1 
A 


(ZEROSP) ,A 
A, (SPEED) 
HL , MARKA 
HL 


HL , DECMK 
A 


Zz 

(HL) 

A, (LASONE) 
1 


Z,MARKB 

a, (ZEROMK) 
A 

5 

Z»MARKC 
(ZEROMK) ,A 


A,5 
(LASONE) ,A 


A,5 

(LASONE) ,A 
BC, 1 

060H 

SPACE 

A 
(ZEROSP) ,A 


A,5 
(LASONE) ,A 
A 
(ZEROSP) ,A 
A, (SPEED) 
HL ,DECMK1 
A 


2 


;ZERO OUT 'A' REGISTER 
AND ZERO MARK COUNTER 
sRETURN WHENCE U CAME +1 
31310-1410 ONLY FOR FLAG 
SPACE TONE PORT ZERO 

31 = SPACE & 5 = MARK 
UPDATE LASTONE 

3ZERO OUT 'A' REGISTER 
;AND ZERO MARK COUNTER 
sCOUNTDOWN VALUE 

7JP (HL) ADDRESS 

3-1 COUNTDOWN VALUE 
sRETURN WHENCE U CAME +1 
3;JUMP TO DECSP1 

3SEND MARK TONE 

;VIA PORT ZERO 

3;ZERO ouT ‘A‘' REGISTER 
sAND ZERO SPACE COUNTER 
sCOUNTDOWN VALUE 

;RETURN MEM LOCATION 
:PUSH ON TOP OF STACK 
3JP (HL) ADDRESS 

3-1 COUNTDOWN VALUE 
:GOTO MARKA WHEN ZERO 
JUMP TO DECMK 

PREVIOUS BIT SENT 

;WAS IT A SPACE ? 

sIF SO, DON'T COUNT IT 
sMARK COUNTER STASH 

3+1 TO MARK COUNTER 

35 MARKS IN A ROW ? 

3;IF SO, DO ZERO INSERTION 
:IF NOT, SAVE NEW VALUE 
32 USEC TIMING ADJUST 
3RETURN WHENCE U CAME +1 
3;SINCE NOT SAME CHANGE IT 
;UPDATE LASTONE 
EQUALIZING DELAY 
sEQUALIZING DELAY 
sEQUALIZING DELAY 
RETURN WHENCE U CAME +1 
31 = SPACE & 5 = MARK 
UPDATE LASTONE 

sDELAY = NO SN2 ITERATION 
sAPPROX. 30 MICROSECONDS 
3DO ZERO INSERTION 

ZERO OUT 'A' REGISTER 
s;AND ZERO SPACE COUNTER 
;RETURN WHENCE U CAME +1 
31770-1870 ONLY FOR FLAG 
SEND MARK TONE 

31 = SPACE & 5 = MARK 
sUPDATE L&STONE 

ZERO OUT 'A' REGISTER 
:AND ZERO SPACE COUNTER 
s;COUNTDOWN VALUE 

sJP (HL) ADDRESS 

7-1 COUNTDOWN VALUE 
;RETURN WHENCE U CAME +1 


01870 JP (HL) JUMP TO DECMK1 
01880 SN1IA LD D,A 31880-2080 ONLY FOR FLAG 
01890 LD E,8 sNUMBER OF BITS PER BYTE 
01900 SN2A LD A, (LASONE) 31 = SPACE & 5 = MARK 
01910 CP 1 sWAS XT A SPACE ? 
01920 JP Z,LASSP 7IF SO, GOTO LAST SPACE 
01930 BIT 0,D 3SET Z FLAG FOR BIT ZERO 
01940 CALL NZ ,MARK1 3IF NOT ZERO SEND MARK 
01950 BIT 0,D :SET Z FLAG FOR BIT ZERO 
01960 CALL Z,SPACE1 3IF ZERO SEND SPACE 
01970 DEC E 3-1 FROM BIT COUNTER 
01980 RET Z 3IF ZERO, RETURN LINE 460 
01990 RRC D :;RIGHT SHIFT ALL 1 BIT 
02000 JP SN2A ;GO BACK FOR NEXT BIT 
02010 LASSP BIT 0,D 3SET Z FLAG FOR BIT ZERO 
02020 CALL NZ,SPACE1 ;IF NOT ZERO SEND SPACE 
02030 BIT 0,D 3SET Z FLAG FOR BIT ZERO 
02040 CALL Z,MARK1 :IF ZERO SEND MARK 
02050 DEC E 3-1 FROM BIT COUNTER 
02060 RET Z 3IF ZERO, RETURN LINE 460 
02070 RRC D ;RIGHT SHIFT ALL 1 BIT 
02080 JP SN2A 3GO BACK FOR NEXT BIT 
02090 ZEROSP DEFB 0 :SPACE COUNTER STASH 
02100 ZEROMK DEFB 0 sMARK COUNTER STASH 
02110 SPEED DEFW 98 ;XMIT COUNTDOWN VALUE 
rer LASONE DEFB 1 ;LAST BIT SENT VALUE 

3 -_> — = Cd Led = ad ad ae ae Ld =~ td ae =a se = ae aselcmemePetl mS Dll -_ - = = 


02140 ;END OF SINGLE/MULTI-FRAME 1200 BAUD SYNCHRONOUS TRANSMIT 


02150 


02160 3; FOR MODEL III CLOCK CHANGE LINE 420 FROM 98 TO 115, 


EoLe 


00100 
00110 
00120 
00130 
00140 
00150 
12790 
12800 
12810 
12820 
12830 
12840 
12850 
12860 
12870 
12880 
T2890 
12900 
12910 
12920 
12930 
12940 
12950 
12960 
12970 
12980 
12990 
13000 
13010 
13020 
13030 
13040 
13050 
13060 
13070 
13080 
13090 
13100 
13110 
13120 
13130 
13140 
13150 
13160 
13170 
13180 
13190 
13200 
13210 
13220 
13230 
13240 
13250 
13260 
13270 
13280 
13290 
13300 
13310 


FIGURE 6 


3 IN-PROGRAM DISK I/O SUBROUTINES FOR AX.25 PROTOCOL 


?} FOR TRSDOS 1.3 


FINISH 
INPNAM 


INNAME 


ESCAPE 


LONG 
LON 1 


LBYTES 
CLRLO 


ORG 
DEFS 
DEFS 


- TRSDOS 2.3 


49632 
32 

256 

A, (HL) 
0 


Z,;FINISH 
033H 

HL 

DIZ 


CLS 
HL,NAM1 
DIZ 

049H 

1 
Z,ESCAPE 
CLS 
HL,NAM1A 
DIZ 
1BB3H 
10H 
1ESAH 
DE, HL 
(DUMP+1) , HL 
(HOWFAR+1) , HL 
CLS 

HL ,NAM2 
DIZ 
1BB3H 
HL, 41E8H 
A, (HL) 

0 


Z2,ESCAPE 
LONG 
HL,41E8H 
DE, FCB 


DRIVE 


AF 

HL,53248 
(DUMP+1) ,HL 
(HOWFAR+1) ,HL 
MENU 

BC,0 

A, (HL) 

0 

Z 

C 

HL 

LON1 

0 

HL, 16872 


- NEWDOS + AND 1.0 


:SUBROUTINE MEM LOCATION 
:DISK FILE CONTROL BLOCK 
sDISK I/O WORKING SPACE 
sDISPLAY MESSAGE ON VIDEO 
sEND OF MESSAGE DELIMITER 
¢ IF ZERO, ALL DONE 
sDISPLAY BYTE ON VIDEO 
sNEXT MESG BYTE LOCATION 
7GO DISPLAY NEXT BYTE 
:RETURN WHENCE U CAME 4H 
3C LEAR VIDEO 
sREMEMBER DELIMITERS MSG? 
sDISPLAY XT ON VIDEO 
sAWAIT KEYBOARD INPUT 
:BREAK KEY PRESSED ? 

:IF SO, ESCAPE LINE 13180 
3C LE AR VIDEO 
:INPUT BEGIN ADDRESS MSG? 
;DISPLAY IT ON VIDEO 
sKEYBOARD INPUT ROUTINE 
3;SCAN STRING SET 'C' FLAG 
s;CONVERT UNSIGNED INTEGER 
:PUT INTEGER IN HL 

;STUFF BEGIN ADDRESS DUMP 
sAND IN HOWFAR MEM 

:C LE AR VIDEO 
sINPUT FILE NAME MESSAGE? 
;DISPLAY IT ON VIDEO 
sKEYBOARD INPUT ROUTINE 
sWHERE STASHED IN MEM 
:FIRST BYTE OF FILE NAME 
:YOU INPUT NOTHING ? 

:IF SO, ESCAPE LINE 13180 
:HOW MANY BYTES IN NAME ? 
:NAME ADDRESS IN MEM 
;FILE CONTROL BLOCK ADR 
sMOVE TO CONTROL BLOCK 
sAND MOVE DRIVE NO. TOO 
;RETURN WHENCE U CAME +1 
sADJUST STACK FOR CALL 
sRESET TO NORMAL 

sDUMP AND 

sHOWFAR 

:TIP MENU FOR INSTRUCTS 
;HOW LONG IS FILE NAME ? 
sBYTE FROM NAME STRING 
sZERO DELIMITER 

sRETURN WITH COUNT 

31 MORE BYTE 

sNEXT MEM LOCATION 

GO COUNT IT 

:NUMBER BYTES READ STASH 
;CLEAR 


13320 
13330 
13340 
13350 
13360 
13370 
13380 
13390 
13400 
13410 
13420 
13430 
13440 
13450 
13460 
13470 
13480 
13490 
13500 
13510 
13520 
13530 
13540 
13550 
13560 
13570 
13580 
13590 
13600 
13610 
13620 
13630 
13640 
13650 
13660 
13670 
13680 
13690 
13700 
13710 
13720 
13730 
13740 
13750 
13760 
13770 
13780 
13790 
13800 
13810 
13820 
13830 
13840 
13850 
13860 
13870 
13880 
13890 
13900 


OPEN1 


READ 


LG 


LONG 1 


CLOSE 


ERROR 


ER1 


ER2 


DRIVE 


DE, 16873 
BC , 12878 
(HL) ,0 


DE,FCB 
HL, BUFFER 
B,0 

4424H 
NZ,ERROR 


HL,53248 
DE, FCB 


HL, DE 


AF 
HL,53248 
(DUMP+1) , HL 
(HOWFAR+1) ,HL 
AF 


OFBDH 


A, (HL) 


CLRHY 
HL,MS2C 
DIZ 
049H 
MENU 
A,@:' 


:LOW MEMORY 

sWITH 

: ZEROS 

3DO IT RIGHT NOW 

sRETURN WHENCE U CAME +1 
sFILE CTRL BLOCK MEM ADR 
*¢DISK I/O BUFFER ADDRESS 
3256 BYTE RECORD LENGTH 
sOPEN AN EXISTING FILE 
32 FLAG SET IF ERROR 
sRETURN WHENCE U CAME +1 
sWHERE TO PUT FILE IN MEM 
3;FILE CTRL BLOCK ADDRESS 
:SAVE MEM LOCATION STACK 
;READ BYTE FROM DISK FILE 
s;RESTORE MEM LOCATION 
AND LOAD IT IN MEM 
sNEXT MEM LOCATION 

SAVE IT IN STACK 

SAVE FCB POINTER 

:FILE END ADDRESS IN MEM 
sCLEAR CARRY FLAG 

3SUB HL = DE SET Z FLAG 
s;RESTORE FCB POINTER 
sRESTORE MEM LOCATION 
:RETURN IF ALL DONE 

3GO READ NEXT BYTE 

sFILE CTRL BLOCK ADDRESS 
sCLOSE FILE SUBROUTINE 
:SAVE IN STACK 

BEGIN HI-MEM ADDRESS 
sRESET DUMP 

;RESET HOWFAR 

sRESTORE AF 

sRETURN UNLESS ERROR 
sADJUST STACK FOR CALL 
7ZERO OUT 'H!® 

;ERROR NUMBER TO ‘'QLL° 
MOVE HL INTO ACCUM 
MAKE SURE AN INTEGER 
sCONVERT TO STRING 
sERROR MESSAGE LOCATION 
sERROR NUMBER 

ZERO STRING DELIMITER 
sALL DONE ? GOTO ER2 
sERROR NUMBER TO MEM 
sNEXT ERROR # LOCATION 
NEST MESSAGE LOCATION 
3GO MOVE NEXT ONE 

sc LEAR VID E.O 
sADJUST STACK 

RESTORE PGM POINTERS 
sCLEAR OUT DOS 

*CLEAR OUT HI-MEM 

sERROR # MESSAGE 
:DISPLAY IT ON VIDEO 
:PRESS ANY KEY 

:GOTO MENU FOR INSTRUCTS 
;DRIVE # SEPARATOR 


vOL'e 


13910 LD 
13920 LD 
13930 INC 
13940 INC 
13950 LD 
13960 LD 
13970 LD 
13980 INC 
13990 INC 
14000 LD 
14010 LD 
14020 LD 
14030 RET 
14040 NAM2 DEFM 
14050 DEFB 
14060 OPEN3 LD 
14070 LD 
14080 LD 
14090 LD 
14100 CALL 
14110 RET 
14120 HOWFAR LD 
14130 FAR1 INC 
14140 LD 
14150 CP 
14160 JP 
14170 INC 
14180 LD 
14190 | CP 
14200 JP 
14210 INC 
14220 LD 
14230 cP 
14240 JP 
14250 INC 
14260 LD 
14270 RET 
14280 DUMP LD 
14290 LD 
14300 DUM1 LD 
14310 PUSH 
14320 CALL 
14330 POP 
14340 JP 
14350 INC 
14360 PUSH 
14370 PUSH 
'T4380 SOFAR LD 
14390 OR 
14400 SBC 
14410 POP 
14420 POP 
14430 RET 
14440 JP 
14450 NAM1 DEFM 
CAPE ELSE <ENTER>'! 
14460 DEFB 
14470 ORG 
14480 SVFILE CALL 


(DE) ,A 
(BC) ,A 
DE 

Bc 
A,*1' 
(DE) ,A 
(BC) ,A 
DE 

Bc 

A, 13 
(DE) ,A 
(BC) ,A 


;FILE CONTROL BLOCK 
;FUTURE USE VOL. 3 

sNEXT FCB LOCATION 
sFUTURE USE VOL. 3 
sDRIVE# CHANGE UR CHOICE 
sINTO FILE CTRL BLOCK 
sFUTURE USE VOL. 3 

:FCB NEXT LOCATION 
sFUTURE USE VOL. 3 

sFCB DELIMITER 

: INTO FILE CTRL BLOCK 
*FUTURE USE VOL. 3 
sRETURN WHENCE U CAME +i 


"INPUT FILE NAME ° 


0 
HL,BUFFER 


NZ,FAR1 
HL 


A, (HL) 
128 
NZ,FARi 


(SOFAR+i) , HL 


DE, 65535 


A 
HL,DE 
DE 

HL 

Z 
DUM1 


"REMEMBER 128 DELIMITERS ? HIT BREAK TO ES 


0 
0c840H 
INPNAM 


;DELIMITER 

DISK I/O BUFFER ADDRESS 
}FILE CTRL BLOCK ADDRESS 
3256 BYTES PER RECORD 
sFILE TYPE DOUBTFUL 
s;OPEN NEW DISK FILE 
sRETURN WHENCE U CAPE +i 
sCALCULATE BYTES TO SAVE 
:TO DISK FILE 

: LOOK 

sFOR 

3 THREE 

: EACH 

: DECIMAL 

2128 

: END 

3 OF 

3 MESSAGE 

3;DELIMITERS 

sIN A 

3 ROW 

:SAVE THEM IN SOFAR 
;RETURN WHENCE U CAME +1 
sBEGIN DATA LOCATION 
FILE CTRL BLOCK ADDRESS 
:BYTE TO SAVE ON DISK 
SAVE BYTE MEM LOCATION 
sWRITE TO DISK SUBROUTINE 
RESTORE BYTE LOCATION 
3Z FLAG SET IF ERROR 
:NEXT BYTE LOCATION 
SAVE IT IN STACK 

SAVE FCB POINTER 

;LAST MEM BYTE LOCATION 
sCLEAR CARRY FLAG 
sSUBTRACT HL MINUS DE 
sRESTORE FCB POINTER 
sAND NEXT MEM LOCATION 
:RETURN IF ALL DONE 

3GO DUMP NEXT ONE TO DISK 


; DELIMITER 
*SAVE FILE MEM LOCATION 
s; INPUT FILE NAME 


MS2C 


LDF ILE 


HIHL 
BAKUP 
BAK1 


TESAGN 


NAMIA 


MULPLY 
MULO 
MUL1 


HOWFAR 
A,195 
(400CH) ,A 
MOVDN 
OPEN3 
DUMP 
‘CLOSE 
SP,29758 
SETUP 
CLRLO 
MENU 
"ERROR # 
0 

OC880H 
INNAME 
CLRHY 
A,195 
(400CH) ,A 
MOVDN 
OPEN1 
MULPLY 
READ 
(HIHL) ,HL 
CLOSE 
SP,29758 
SETUP 
CLRLO 
BAKUP 
MENU 

0 

HL, (HIHL) 


Z , TESAGN 
HL 
(BEFORE) , HL 


NZ ,BAK1 
(BEFORE) ,HL 


s:CALCULATE BYTES TO SAVE 
:RESTORE JUMP 

:TO LOW MEMORY 

sMOVE DOS BACK DOWN MEM 
;OPEN OR CREATE DISK FILE 
sDUMP IT TO DISK 

sCLOSE TME DISK FILE 
;RESET STACK POINTER 
sREINITIALIZE PGM PTRS 
sCLEAR OUT DOS LO-MEM 
sGO FOR INSTRUCTIONS 
;DISK I/O ERROR MESSAGE 
sDELIMITER 

LOAD FILE MEM LOCATION 
INPUT FILE NAME 

zCLEAR HI-MEMORY 
sRESTORE JUMP 

3;TO LOW MEMORY 

sMOVE DOS BACK DOWN MEL; 
sOPEN AN EXISTING FILE 
sCALCULATE FILE LENGTH 
LOAD FILE TO HI-MEMORY 
*SAVE HI-MEM END OF FILE 
sCLOSE DISK FILE 

;RESET STACK POINTER 
sREINITIALIZE PGM PTRS 
sCLEAR OUT DOS LO-MEM 
:CHECK EXTRA FILE DATA ? 
:MENU FOR INSTRUCTIONS 
sEND HI-MEM FILE STASH 
:! §! VOLUME 3 ONLY !1! 
:THIS 

sSCINTILLATING 

: ROUTINE 

:; TRIES 

3TO 

3 BACKUP 

:IN HI-MEMORY 

;TILL IT 

;IT 

sFINDS 

33 EACH 

3128'S IN 

sA ROW. 

;WHEN FOUND 

IT RESETS BEFOR,. 

:SO THAT WHEN THE PROGRAM 
sAUTOMATICALLY MOVES THE 
;FILE DOWN, ONLY DATA IS 
sMOVED. ! VOLUME 3 ONLY ! 


"INPUT BEGINNING MEM ADDRESS (53248 NOMINA 


0 


A, (FCB+12) 


HL,0 
DE, 256 
HL,DE 


A 


Z,MUL2 


;DELIMTER 

s;NUMBER RECORDS IN FILE 
3ZERO OUT BYTE COUNTER 
BYTES PER RECORD 


;ADD THEM UP 
MINUS ONE RECORD 


sALL DONE, GOTO MUL2 


SOLS 


15070 
15080 
15090 
15100 
15110 
15120 
15130 
15140 
15150 
15160 
15170 
15180 
15190 


me mE 


JP MUL1 
MUL2 LD A, (FCB+8) 
LD E,A 
LD D,0 
ADD HL, DE 
MUL3 LD (LBYTES) ,HL 
BD DE, 53248 
ADD HL,DE 
LD (LONG1+1) ,HL 
RET 


ADD UP NEXT ONE 

:BYTES IN LAST SECTOR 
*STUFF IN ‘E! 

ZERO OUT 'D' 

sADD THEM UP 

;AND SAVE THEM HERE 
:BEGIN HIGH MEMORY 

3;ADD BYTES TO HI-MEM 
;AND SAVE THEM HERE 
;RETURN WHENCE U CAME +1 


END OF VOLUME 2 -— DISK I/O SUBROUTINES 


00100 
00110 
00120 
00130 
00140 
00150 
00160 
05230 
05240 
05250 
05260 
05270 
05280 
05290 
05300 
05310 
05320 
05330 
05340 
05350 
05360 
05370 
05380 
05390 
05400 
05410 
05420 
05430 
05440 
05450 
05460 
05470 
05480 
05490 
05500 
05510 
05520 
05530 
05540 
05550 
05560 
05570 
05580 
05590 
05600 
05610 
05620 
05630 
05640 
05650 
05660 
05670 
05680 
05690 
05700 
05710 
05720 
05730 
05740 


FIGURE 7 


; IN-PROGRAM EDIT/MODIFY/MONITOR SUBROUTINE = 866 BYTES 


3 ALSO USED FOR KEYBOARD INPUT PACKET MESSAGES 


ORG 38912 
DISMEM LD HL, 40960 
DISEM1 LD (MEMO) , HL 
DISPLA LD HL, (MEMO) 

LD (LASMEM) , HL 

DEC HL 

LD (MEMO1) ,HL 

INC HL 

ED DE, 15360 

LD BC,1024 
AGAIN LD A, (HL) 

BIT 7,A 

CALL Z,SET6 

BIT 7,A 

CALL NZ, RES6 

LD (DE) ,A 

INC HL 

INC DE 

DEC Bc 

LD A,B 

CP 0 

JP Z, TESTIT 

JP AGAIN 
RES6 RES 6,A 

RET 
SET6 BIT 6,A 

RET NZ 

BIT 5,A 

RET NZ 

SET 6,A 

RET 
TESTIT LD A,C 

CP 0 

JP NZ,AGAIN 

LD (MEMO), HL 
NEXT CALL 049H 

CP 1 

JP Z,7630H 

Cp 13 

JP Z,DISPLA 

CP 45 

JP Z,BACKUP 

cP 1 

JP Z,MODIF 

JP NEXT 
BACKUP LD HL, (MEMO1) 

INC HL 

LD (MEMO) ,HL 

DEC HL 

LD DE, 16383 

LD BC,1024 


AGAIN1 LD A, (HL) 


: SUBROUTINE MEM LOCATION 
:;CURRENT PACK LOCATION 
;TOP OF PAGE STASH 

*BACK TO HL REGISTER 
:INC/DEC STASH 

sMINUS ONE 

sBOTTOM PREVIOUS PAGE 
7TOP OF THIS PAGE OF MEM 
BEGINNING VIDEO MEMORY 
:BYTES PER PAGE OF VIDEO 
CHANGE MODEL III 

:VIDEO DISPLAY 

;TO SIMILAR TO 

s:MODEL I 

:VIDEO DISPLAY 

:STASH BYTE IN VIDEO 
:NEXT BYTE FROM MEMORY 
:NEXT VIDEO DISPLAY MEM 
:BYTES TO MOVE COUNTER 
sTEST B 

:IF ZERO 

:TEST C 

:ELSE MOVE NEXT BYTE 
:ZERO OUT BIT 6 

:RETURN WHENCE U CAME +1 
*TEST BIT 6 

:RETURN IF SET TO 1 
*TEST BIT 5 

sRETURN IF SET TO 1 

:IF NOT, SET BIT 6 TO 1 
sRETURN WHENCE U CAME +1 
:;BYTES TO MOVE COUNTER 
ZERO ? 

;IF NOT, MOVE NEXT ONE 
;TOP NEXT PAGE MEMORY 
;AWAIT KEYBOARD INPUT 
*BREAK KEY ? 

;IF SO, GOTO PIP MENU 
ENTER KEY ? 

;IF SO, DISPLAY NEXT PAGE 
;MINUS KEY ? 

3IF SO DISPLAY LOWER PAGE 
:'M' KEY PRESSED ? 

;IF SO, GOTO MODIFY MODE 
sELSE IGNORE IT 

;MOVE THE 

;VIDEO DISPLAY 

;DOWN A FULL PAGE 

«IN MEMORY 

;LAST BYTE VIDFO MEMORY 
sFULL PAGE VIDEO BYTES 
;CHANGE MODEL III 


9°oL’s 


05750 
05760 
05770 
05780 
05790 
05800 
05810 
05820 
05830 
05840 
05850 
05860 
05870 
05880 
05890 
05900 
05910 
05920 
05930 
05940 
05950 
05960 
05970 
05980 
05990 
06000 
06010 
06020 
06030 
06040 
06050 
06060 
06070 
06080 
06090 
06100 
06110 
06120 
06130 
06140 
06150 
06160 
06170 
06180 
06190 
06200 
06210 
06220 
06230 
06240 
06250 
06260 
06270 
06280 
06290 
06300 
06310 
06320 
06330 


TESIT 


LASMEM 
MODIF 


CONT3 


CONT3B 


JP 


LD 


0 

Z,TESIT 
AGAIN1 

A,C 

0 

NZ ,AGAIN1 
(MEMO1) , HL 


HL 
(LASMEM) , HL 
NEXT 

0 

IX, 15360 
IY, (LASMEM) 
BLINK-9 

A, (LNFEED) 
1 


2, LFEED2 
BLINKB 


02BH 


Z,CONT3 
(HOLDZ) ,A 
A, (UPSIDE) 
0 


NZ, INVERT 
A, (HOLDZ) 


sVIDEO DISPLAY 

3;TO SIMILAR TO 

sMODEL I 

3; VIDEO DISPLAY 

sSTASH BYTE IN VIDEO 
sNEXT LOWER BYTE MEMORY 
;NEXT LOWER BYTE VIDEO 
sDECREMENT BYTE COUNTER 
sTEST B 

:IF ZERO 

:TEST C 

sELSE MOVE NEXT BYTE 
sTEST C 

;FOR ZERO 

;IF NOT, MOVE NEXT BYTE 
:BOTTOM NEXT PAGE DOWN 
e¢TOP THIS PAGE OF MEM 
sAND SAVE THIS LOCATION 
3GO AWAIT NEXT COMMAND 
3;MEM STASH 

sMODIFY MODE = MODIFY 
:BOTH VIDEO & REAL MEMORY 
sBLINKING CURSOR 
;LINEFEED AFTER CARRET? 
sIF so 

sSTUFF IT IN MEMORY 
sRESTORE MEM CHARACTER 
KEYBOARD ROW PSUEDO MEM 
BREAK KEY PRESSED ? 

sIF SO, RESUME EDIT MODE 
gLEFT ARROW KEY PRESSED ? 
sMOVE CURSOR BACK A SPACE 
sRIGHT ARROW KEY PRESSED? 
;MOVE CURSOR AHEAD SPACE 
:DOWN ARROW KEY PRESSED 3 
MOVE CURSOR DOWN 1 LIN 
3;UP ARROW KEY PRESSED ? 
sMOVE CURSOR UP 1 LINE 
3;SHIFT KEY PSUEDO MEM 
gEITHER SHIFTKEY PRESSED? 
sIF SO, TEST NOT ASCII 
;KEYBOARD TO 'A' 
s;SUBTRACT 11 

sIF MINUS, IGNORE IT 
gENTER KEY ? 

sSETUP AUTO LINE FEED 
3;SPACE ? 

3;TEST ILLEGAL SHIFT 

3@ KEY 3 

:IF SO, IGNORE IT 

3;UP ARROW ? 

sIF SO, IGNORE IT 

;SHIFT @ ? 

sIF SO, IGNORE IT 

sSAVE BYTE INPUT 

sTEST FOR LOWERCASE 

sIF SO 

sINVERT IT 

;RESTORE BYTE INPUT 


06340 

06350 

06360 

06370 CONTS 
06380 

06390 

06400 

06410 

06420 

06430 LFEED1 
06440 

06450 

06460 

06470 

06480 LFEED2 
06490 

06500 

06510 

06520 LNFEED 
06530 LEFT1 
06540 

06550 

06560 

06570 

06580 RIGHT1 
06590 

06600 

06610 

06620 

06630 UPONE 
06640 

06650 

06660 

06670 

06680 DOWN1 
06690 

06700 

06710 

06720 

06730 CONT3A 
06740 

06750 CKBACK 
06760 

06770 

06780 

06790 

06800 

068 10 CKAHED 
06820 

06830 

06840 

06850 

06860 

06870 CKDOWN 
06880 

06890 

06900 

06910 

06920 CKUP 


1 
(LNFEED) ,A 
AF 


A 
(LNFEED) ,A 
A,10 

CONTS 

0 


SLOWLY 
CKBACK 
IX 
IY 
CONT3 
SLOWLY 
CKAHED 
IX 
Ty 
CONT3 
SLOWLY 
SLOWLY 
CKDOWN 
SUB64 

CONT3 
SLOWLY 
SLOWLY 

CKUP 

ADD64 

CONT3 

HL 

CONT3 

DE, 15360 
IX 

HL 

OA39H 

Z,CONT3A 


DE, 16383 
IX 

HL 

0A39H 
Z,CONT3A 


SUB64A 
DE, 15360 
OA39H 
C,CONT3A 


ADD64A 


;SUBTRACT 65 

3MINUS JUMP AROUND RESET 
sRESET BIT 5 

sDISPLAY BYTE ON VIDEO 
LOAD BYTE INTO RAM MEM 
sNEXT LOCATION IN BOUNDS? 
20K SO, INCREMENT VIDEO 
sAND MEMORY LOCATION 

3GO SCAN FOR NEXT INPUT 
SAVE CARRET BYTE 

sSTUFF 1 INTO 

;AUTO LINE FEED POINTER 
3RESTORE CARRIAGE RETURN 
s;RETURN WHENCE U CAME +1 
:ZERO OUT 

s;LINEFEED POINTER 

sASCII 10 = LINEFEED 

3GO STUFF IT IN MEMORY 
sLINEFEED POINTER STASH 
;SLOWDOWN CURSOR MOVEMENT 
sCHECK IN BOUNDS ? 

30K, MOVE BACK A SPACE 
AND DOWN 1 MEM LOCATION 
3GO SCAN NEXT INPUT 

s SLOWDOWN CURSOR MOVEMENT 
3CHECK IN BOUNDS ? 

30K, MOVE AHEAD A SPACE 
sAND UP 1 MEM LOCATION 
GO SCAN NEXT INPUT 
?SLOWDOWN CURSOR MOVEMENT 
sSLOWDOWN CURSOR MOVEMENT 
:CHECK IN BOUNDS ? 

30K, SO MOVE UP A LINE 
:GO SCAN NEXT INPUT 
sSLOWDOWN CURSOR MOVEMENT 
:SLOWDOWN CURSOR MOVEMENT 
sCHECK IN BOUNDS ? 

70K, SO MOVE DOWN A LINE 
?GO SCAN NEXT INPUT 
sADJUST STACK 

3GO SCAN NEXT INPUT 
BEGIN VIDEO MEMORY 

:SWAP Ix 

sINTO HL 

sCOMPARE HL MINUS DE 

3IF EQUAL, THEN IGNORE 
ELSE OK. RETURN 

END OF VIDEO MEMORY 
sSWAP Ix 

3s INTO HL 

s;COMPARE HL MINUS DE 

;IF EQUAL, THEN IGNORE 
ELSE OK. RETURN 

¢-64 FROM VIDEO MEM 
:BEGIN VIDEO MEM 

sCOMPARE HL = DE 

3IF OUT OF BOUNDS, IGNORE 
ELSE OK. RETURN 

3+64 TO VIDEO MEM 


06930 
06940 
06950 
06960 
06970 
06980 
06990 
07000 
07010 
07020 
07030 
07040 
07050 
07060 
07070 
07080 
07090 
07100 
07110 
07120 
07130 
07140 
07150 
07160 
07170 
07180 
07190 
07200 
07210 
07220 
O7ZZ30 
07240 
07250 
07260 
07270 
07280 
07290 
07300 
07310 
07320 
07330 
07340 
07350 
07360 
07370 
07380 
07390 
07400 
07410 
07420 
07430 
07440 
07450 
07460 
07470 
07480 
07490 
07500 
07510 


SUB64A 


AGN64S 


ADD64A 


AGN64A 


SUB64 


AGNSUB 


ADD64 
AGNADD 


HNOLDIT 
SLOWLY 


BLINKA 


BLINKB 


INVERT 


DE, 16384 
0A39H 
NC ,CONT3A 


IX 
HL 
A,64 
HL 


AGNSUB 
A,64 
IX 

ry 
A 

Z 
AGNADD 


0 
BLINKA 
BLINKB 
BLINKA 
BLINKB 
BLINKA 
BLINKB 
BLINKA 
BLINKB 


A, (IX) 


(HOLDIT) ,A 


A, 143 
(IX) ,A 
BC ,600 
060H 


A, (HOLDIT) 
(IX) ,A 

BC ,600 
060H 


A, (HOLDZ) 


sEND VIDEO MEM 
;COMPARE HL = DE 
sIF OUT OF BOUNDS, IGNORE 
sELSE OK. RETURN 
sSWAP IX 

sINTO HL 

;WE COULD HAVE 
sUSED ADD HL,DE 
:BUT THERE IS MORE 
sTHAN ONE WAY TO 
sSKIN A CAT 

s:SWAP IX 

3s INTO HL 

:WE COULD HAVE 
;USED SBC HL,DE 
¢BUT THERE IS MORE 
:THAN ONE WAY TO 
SKIN A CAT 

sHERE IS ANOTHER 
sPLACE YOU MIGHT 
sWISH TO USE 

3SBC HL,DE 

sHOW MANY BYTES 
sDID IT SAVE ? 
sHERE IS ANOTHER 
sPLACE YOU MIGHT 
:WISH TO USE 

;ADD HL,DE 

;HOW MANY BYTES 
sDID IT SAVE ? 
;HOLDIT STASH 

7S Cc M 


7L u @) 

: O R V 

3 W s E 

7 D 0 M 

; @) R EK 

: W N 
: N T 


sRETURN WHENCE U CAME +1 
?;SAVE VIDEO BYTE 

;IN HOLDIT 

:RECTANGULAR CURSOR 
:DISPLAY ON VIDEO 
:1/100TH SECOND 

TIME DELAY 

:RETURN WHENCE U CAME +1 
*RESTORE VIDEO CHARACTER 
:TO VIDEO MEM LOCATION 
21/100TH SECOND 

sTIME DELAY 

sRETURN WHENCE U CAME +1 
s INVERT UPPER/LOWER CASE 
sSUBTRACT 65 

;NOT ALPHABETICAL IGNORE 
sSUBTRACT 123 

:NOT ALPHABETICAL IGNORE 
;SUBTRACT 95 

;NOT ALPHABETICAL IGNORE 


07520 
07530 
07540 
07550 
07560 
07570 
07580 
07590 
07600 
07610 
07620 
07630 
07640 
07650 
07660 
07670 
07680 
07690 
07700 
OTT 1G 
07720 
07730 
07740 
07750 
07760 
07770 
07780 
07790 
07800 
07810 
07820 
07830 
07840 
07850 
07860 
07870 
07880 
07890 
07900 
07910 
07920 
07930 
07940 
OW 93:0 
07960 
07970 
07980 
07990 
08000 
08010 
08020 
08030 
08040 
08050 
08060 
08070 
08080 
08090 
08100 


SET5A 
HOLDZ 


UPSIDE 
CK 


COR 


ONE28 


NOTASC 


AF 


CONT3 
SLOWLY 
SLOWLY 


Z,29760 
A, (14352) 
1 


Z,ONE28 
A, (14337) 
1 
NZ,CONT3B 
CLS 
CARETN 
HL, VALMS 
DIZPLA 
HL,0 
HL,SP 
OA9AH 

A 

1034H 
(HL) 
OFD9H 
DIZPLA 
CARETN 
CARETN 
HL, VALMSO 
DIZPLA 

TY. 

HL 

OA9AH 

A 

1034H 
(HL) 
OFD9H 
DIZPLA 
CARETN 
CARETN 
HL, VALMS1 
DIZPLA 

A, (IY) 


3sBIT 5 SET ? 

3IF NOT, THEN SET XT 
sELSE RESET IT 

;AND DISPLAY IT 

:SET BIT 5 TO DISPLAY 
;AND DISPLAY IT 

sBYTE STASH 

sLOWER CASE POINTER 
:SAVE BYTE 

sSHIFT KEY PRESSED ? 

IF SO 

IGNORE IT 

sRESTORE BYTE 

sCONTINUE ONWARD 

sADJUST STACK FOR PUSH 
3GO SCAN NEXT INPUT 
:SLOWDOWN AS THIS IS AN 
sAUTO REPEAT FUNCTION 
sEND OF MESSAGE DELIMITER 
:STUFF IT IN MEM & VIDEO 
sELECTRIC PENCIL CTPL REY 
s;REINITIALIZE PGM POINTER 
sKYBD ZERO PSUEDO MEMORY 
;SHIFT ZERO PRESSED ? 
sEND OF MESSAGE DELIMITER 
:KYBD @ PSUEDO MEMORY 

3@ KEY PRESSED ? 

;IF NOT, CONTINUE ONWARD 
sc LEAR VIDEO 
VIDEO SKIP A LINE 
STACK POINTER MESSAGE 
sDISPLAY IT ON VIDEO 
*ZERO OUT HL 

;ADD IT TO STACK VALUE 
MOVE IT TO ACCUM 

3; ZERO OUT 'A' 

: GENERATE 

s UNSIGNED 

s INTEGER 

sDISPLAY IT ON VIDEO 
;VIDEO CARRIAGE RETURN 

: VIDEO CARRIAGE RETURN 
:;MEMORY LOCATION MESSAGE 
:DISPLAY IT ON VIDEO 
:SWAP IY MEM LOCATION 
sINTO HL 

sMOVE HL TO ACCUM 

:ZERO OUT 'A' 

: GENERATE 

; UNSIGNED 

: INTEGER 

sDISPLAY IT ON VIDEO 

; VIDEO CARRIAGE RETURN 

3; VIDEO CARRIAGE RETURN 
3;MEM VALUE MESSAGE 
sDISPLAY IT ON VIDEO 

;IY LOCATION MEM VALUE 

zs INTO 'L' 

3ZERO OUT ‘'H' 


SOL’ 


08110 CALL OASAH ;MOVE HL TO ACCUM 08700 


POP IX ; KITCHEN 
08120 CALL OFBDH sCONVERT ACCUM TO STRING 08710 POP HL 3THE 
08130 CALL DIZPLA ,AND DISPLAY IT ON VIDEO 08720 POP DE INCLUDING 
08140 CALL  CARETN ;VIDEO CARRIAGE RETURN 08730 POP BC }EVERTHING 
08150 CALL CARETN sVIDEO CARRIAGE RETURN 08740 POP AF *RESTORE 
08160 LD HL , VALMS2 ;INPUT NEW MEM MESSAGE 08750 RET ;RETURN WHENCE U CAME +1 
08170 CALL DIZPLA ;DISPLAY IT ON VIDEO 08760 : 

08180 LD BC , 32000 31/2 SECOND OB770 9:2 er ire et eit a Se a ee i es 
08190 CALL 060H 3TIME DELAY 08780 ; END OF EDIT/MODIFY/MONITOR SUBROUTINE 
08200 CALL 1BB3H 3 INPUT NEW VALU FROM KYBD 

08210 RST 10H ;SCAN STRING SET 'C' FLAG 

08220 CALL OE6CH sASCII $ TO ACCUM RET MIN 

08230 CALL OA7FH s;CONVERT ACCUM TO INTEGER 

08240 LD A,L sNEW MEM VALUE 

08250 LD (IY),A ;AND STUFF IT IN MEMORY 

08260 NOTAS LD HL, (LASMEM) :BEGINNING MEM LOCATION 

08270 LD DE, 15360 sBEGINNING VIDEO MEM 

08280 LD BC, 1024 ;RESTORE VIDEO ALMOST 

08290 LDIR *SAME AS BEFORE 

08300 CALL CKAHED :TEST VIDEO IN BOUNDS ? 

08310 INC IX 30K, SO MOVE CURSOR AHEAD 

08320 INC IY 3& INCREMENT MEM LOCATION 

08330 JP CONT3 :GO BACK & SCAN KEYBOARD 

08340 VALMS DEFM 'STACK POINTER = ' 

08350 DEFB 0 *DELIMITER 

08360 VALMSO DEFM "MEM LOCATION Is * 

08370 DEFB 0 ; DELIMITER 

08380 VALMS1 DEFM "MEMORY VALUE IS ° 

08390 DEFB 0 :DELIMITER 

08400 VALMS2 DEFM 'INPUT NEW VALUE ° 

08410 DEFB 0 ;DELIMITER 

08420 MEMO DEFW 0 ¢;MEMORY LOCATION STASH 

08430 MEMO1 DEFW 0 7;MEM LOCATION STASH -1 

08440 NEXT2 LD BC, 24000 sABOUT 1/3 SECOND 

08450 CALL 060H ;TIME DELAY 

08460 JP NEXT :AWAIT EDIT MODE COMMAND 

08470 CARETN LD A,13 3 VIDEO 

08480 CALL 033H sCARRIAGE RETURN 

08490 RET RETURN WHENCE U CAME +1 

08500 CLS LD HL, 15360 ;BEGIN VIDEO MEM 

08510 LD DE, 15361 PLUS ONE 

08520 LD BC, 1023 :BYTES TO CLEAR 

08530 LD (HL) , 32 ;WITH SPACES 

08540 LD (16416) , HL :RESET VIDEO CURSOR 

08550 LDIR sMOVE'M RIGHT NOW 

08560 RET ;RETURN WHENCE U CAME +1 

08570 DIZPLA PUSH AF 3SAVE 

08580 PUSH BC sg EVERTHING 

08590 PUSH DE 3 INCLUDING 

08600 PUSH HL 7THE 

08610 PUSH IX : KITCHEN 

08620 PUSH IY 3SINK 

08630 MORE1 LD A, (HL) :BYTE TO DISPLAY 

08640 CP 0 END MESSAGE DELIMITER 

08650 JP Z,FINIS1 gIF SO, ALL DONE 

08660 CALL 033H gDISPLAY & UPDATE CURSOR 

08670 INC HL 3MESSAGE MEM LOCATION 

08680 JP MORE 1 _3GO DISPLAY NEXT ONE 


08690 FINIS1 POP IY SINK 
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ABSTRACT: 


AUTO connect/disconnect mode rmong 
unattended operation is available with the 
Vancouver Area Digital Communications 
Groups terminal node controller (TNC), the 


Tucson Amateur Packet Radio TNC, and 
"Synchronous Packet Radio Using The 
Software Approach = AX.25 ProLocol 


software TNC. 


A logical expansion of the auto mode's 
capabilities would be to allow the station 
to which your station is connected in the 
AUTO mode to have full access to one or 
more of your disk drives. Minimum 
functions would include: LIST the disk 
directory, SEND a given disk file, SAVE a 
given file on disk, and send a set of 
operating instructions upon receiving the 
HELP command. 


It is obvious that a disk I/O system 
subroutine such as this in the AUTO mode, 
is indeed in essence a mini-sized version 
of a computer bulletin board system. By 
the term ‘Possible Standard* in this 
paper's title, we are suggesting that it 
would be a "nice -to have feature' 
incorporated in all packet stations 
regardless of the protocol or TNC used. 


This paper describes the subroutines 
used by the author to provide these 
functions on a Model I TRS-80 with the 
packet radio software approach using the 
Vancouver protocol. 


GENERAL: 


These subroutines were written = and 
tested during the summer of 1983. Why did 
they use the Vancouver protocol? Quite 
Simply because at that time in the western 
New York and southern Ontario regions there 
were no AX.25 stations (other than the 
author's software approach) on the 2 meter 
band. Southern Ontario (in the vicinities 
of Hamilton and_ Toronto) had about 50 
active packeteers, all using the Vancouver 
TNC with Vancouver protocol, and the 
Buffalo, NY area 65 miles northeast of our 
QTH had Gil Boelke = W2EUP, using the 
Vancouver protocol with the GLB PK-1 
software approach. 


W2EUP convinced us of the value of 
implementing disk I/O in the AUTO mode with 


N.Y. 14722 


a number of demonstrations, so we wrote the 
following subroutines. They are designed 
to work only with the following Model I 
TRS-80 disk operating systems: TRSDOS 2.3, 
NEWDOS + and NEWDOS 1.0. 


Figure 1 is the commented source code 
imoug this subroutine. The comments are 
largely self explanatory. The equates 
(EQU) at the beginning of the program serve 
to link these AUTO mode subroutines to. the 
main software program used in Volume 3 of 
‘Synchronous Packet Radio Using The 
Software Approach # Advanced Vancouver 
Protocol.” 


Though only the SEND, SAVE, LIST, and 
HELP commands are used in this 
mini-subroutine it is a relatively simple 
matter to expand the commands to- include 
FLAGS xxx to set the program's number of 
opening flags transmitted, DELETE file name 
to do just that, and to include the disk 
drive number with the file name so any 
number of disk drives from 1 to 4 may be 
accessed. 


Depending upon how far you wish to go, 
this fundamental program may be expanded up 
to and including all of the features of a 
full sized computer bulletin board system. 


Originally, the AUTO disk I/O 
subroutines required a carriage return and 
line feed immediately after each command to 
eliminate the possibility of having the 
program confuse an info field in a frame 
that began with SEND, SAVE, LIST or HELP as 
a command rather than part of the message. 
Since the commands must be in capital 
letters, this has not occurred during the 
past 9 months of operation so the mandatory 
Carriage return and line feed requirements 
were removed to further simplify operation. 
By all means put them back in if you wish. 


W2EUP's and K2IMF's AUTO mode disk I/0 
programs require that each command begin 
with the / character; i.e., /SEND, /SAVE, 
GLST: and /HELP to avoid possible 
confusion. This is yet another approach 
you might consider. 


Figure 2 is the HELP message the 
program sends in the AUTO mode upon 
receiving the HELP command in a_e single 
frame packet after the connection is 
established. The capital M's represent 
ASCII 13 carriage returns and the capital 
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3% represent ASCII 10line feeds. They 
are included, as some of the dumb terminals 
now used with some packet TNCs do not have 
the automatic scrolling feature. 


CONCLUSION: 


Expanding the auto connnect mode's 
capability to include disk I/O has proven 
extremely useful. We are grateful to W2EUP 
EO the concept and for continued 
encouragement. 


Volume 3 of @Synchronous Packet Radio 
Using The Software Approach = Advanced 
Vancouver Protocol’ has not been published 
and probably never will be published. 

WHY ? 

Quite simply the brilliant AX.25 
protocol is taking the world by storm. Its 
growth capabilites and myriad other 
advantages over the older Vancouver 
protocol have just about buried the old 
timer once and for all except in the 
immediate Toronto, Vancouver, and Melbourne 
environs. 


The other reason ‘Advanced Vancouver 
Protocol' may never be published is simply 
the costs involved. It takes a minimum of 
200 sales per volume just to break even and 
with the greatest stretch of our wildest 
imagination we cannot forsee 200 
knowledgeable radio amateurs springing for 
yet another Vancouver protocol book. 


If you feel you must have a copyof 
the uncommented source and object code for 
Volume 3, available only for the Model I 


TRS-80, on a single, DOUBLE sided, 35 track 
disk, with no instructions or assistance 
whatsoever other than a short single page 


telling you how to install your own call 
letters and node number in the program, 
then send Richcraft acheck for $29 and the 
disk will be mailed to you first class. 


Richcraft Encineering Ltd. 
#1Wahmeda Industrial Park 
Chautauqua, New York 14722 


NOTE: 

The main and shift menus of the Volume 
° program are Similar to the menus 
illustrated in Figure 2 of the iy Gas 
Protocol paper by the sane author that is 
presented elsewhere in these proceedings. 


VOLUME 3 MAIN MENU; 


CHANGE ADDRESSEE CALL 

NOT CONNECTED TOGGLE 

SEND PACKETS FROM LO=MEIM 
INPUT FPRAMES/PACKET LO-MEM 


ENTER OPTION DESIRED 3 es 


BACKOFF DELAY TOGGLE OFF 


NOW IN UPPER CASE MODIFY 
DISPLAY/EDIT MEMORY PAGE 
NOT FORMAT VIDEO TOGGLE 
TRANSMIT EXTERNALLY ONLY 
TRANSMIT TO III-MEM ONLY 
CLEAR NON-PGM MEM 17K-62K 
ABORT LOW-MEY PAK SEQUENCE 


SHIFT MENU 


SEND WAIT REQUEST (RNR) 


Ww-KANOOSZRH|AMNA 


VOLUME 3 SHIFT MENU: 


A 


W2EUP CONNECT REQUEST CQ = 
W2EUP DISCONNECT REQUEST 2 
W2EUP CONNECT ACKNOWLEDGE = 
THIS IS VANCOUVER PROTOCOL 
AUTO CONNECT TOGGLE OFF 

W2EUP + GIL BOZLKE MESSAGE 
SET INFO FIELD LOMEM PACKS 
QUICK BROWN FOX MESSAGE 

SET OPENING FLAG LENGTH 

INPUT/XMIT NORMAL INFO 3 V 
INPUT/XMIT ALL STATION = V 
SET RF-TRY IN CONNECT MODE 
MOVE HI-MEM TO LOW-MEM 

SEND CLEAR WAIT 


SHIFT MENU ? _ 


XMIT 40960 UP CONTINUOUSLY = 


LOAD HI-MEM ASCII UUUULUU 
EDIT/MODIFY INSTRUCTIONS 
LOG ON VE3MHZ REPEATER 
SEND MORSE I.D. 

CAUTION ** RESTORE DOS ** 
DISPLAY RCCV PACKS @ 53248 
DISPLAY CALL/ADDRESS LIST 
SAVE HI-MEM ON DISK 


TRANSMIT BAUD RAT 
CLEA? HI-MEMORY 53248 + 

RECEIVE AX.25 NOT CONNECT 
NORMAL DISPLAY = NOT DPLL 
SPACE BAR IN REC 


NOTE: 


TE SELECT 


BOOT DOS READY 
LOAD HI-MEM LOGIC 1111111 
CHANGE RECEIVE DPLL BASE $ 
LOG OFF VE3MHiZ REPEATER 
SEND SEQUUNTIAL ACKS 
DISPLAY LOW MEMORY @ 17408 
RESTORE PROCRAM POINTERS 
MOVE PROGRAM TO LOW MEMORY 
LOAD DISK FILE TO HI-MEM 
SEND DISK :1 DIRECTORY 
RECEIVE YANCOUYER PROTOCOL 
SEND MORSE FROM KEYBOARD 
DISPLAY DPLL LAST QUADRANT 


A 
C 
E 
G 
E 
K 
M 
0 
Q 
S 
U 
W 
Y 
E 


VOLUME 3 CALL & ADDRESS LIST 


VE7APU = 196 
(DOUG) 
VE3DNM = 98 


(MAX) 
VESEC = 236 
(BILL) 


VE3FGK = 218 
(DAVE) 
VE3IUV = 116 
(RON) 

VE3PKT = 186 
(MAIL BOX) 
K2IMF = 41 
(DON) 


(SUMMER ‘83): 


= CALL AND ADDRESS LIST 


VE3ATI = 51 
(BERNIE) 
VE3DSP = 97 
(GLEN) 


VE3EHL = 117 


(ED) 


VE3FMG = 120 


(MIKE) 


VE3LNY = 181 


(JACK) 

WA2RYT = 129 
(RAY) 

WB2VEU = 65 
(ANDY) 


VE2BAR = 215 
(MIKE) 
VE3DVV = 115 
(JOHN) 

W2EUP »® 119 
(GIL) 

VE3GBC = 216 
(BRUCE) 
VE3MWM = 185 
(STU) 

VE3SP = 118 
(RON) 

W4UMF = 28 
(TOM) 


POTENTIAL OSCAR 10 PACKETEERS (SUMMER '83): 


U.S.A. 
KA1GD ANDY 
K2IMF DON 
K4BRK CARL 
W4UCH BOB 
KA6M HANK 
We8KOX TOM 
KASNZI GARY 
OVERSEAS: 
OK2SPS PETER 
CANADA 
VE2BAR MIKE 
VE3DNM MAX 
VE3EC BILL 
VE3FMG MIKE 
VE3LNY JACK 


3.110 


KATHTV UNK 

WA2 LQQ GRUM 
K4CAV CHAS 
W4UMF TOM 

W6O0VP DAVE 
W9 BD FRED 
KA9IQ. PHIL 


SMSHEV JENS 
VE2BPD JEAN 


VE 3DRZ ROB 
VE3EHL ED 


VE3GRC BRUCE 


VE3MWM STU 


= POTENTIAL OSCAR 10 PACKET LIST AS 


WAILOU STAN 
WB2VEU ANDY 
WB4JFI TERRY 
WA6JPR WALT 
W6TNS DON 

WBOPLW PETE 
NOCCZ ANDY 


VK2BOA TONY 


VE3ATI BERNIE 
VE3DSP GLEN 
VE3PAO FRANK 
VE3IAC PAUL 
VE3NEC JOUN 


(RR) 


BNK EHD UBSray cow 


Hnedoman wpa 


auupnunnturanas 
NM SCNTDUAZHPAe TO 


IVE MODE = RESEND LAST PACK 


VE3BKB = 220 


(Jon) 

VE3DR2 = 239 
(ROB) 
VE3FAO = 250 
(PRANK) 
VE3IAC = 238 
(PAUL) 
VE3NEC = 210 
(JOHN) 

VE3UR = 221 
(RAY) 

W2cIX = 30 
(BILL) 


oF 8/15/83 « 
W2EUP GIL 
W3IWI TOM 
W4RI PAUL 
NK6K HAL 
WA7GXD LYLE 


KING STEVE 
KROU TIM 
ZL1AOX IAN 


VE3BKB JON 
VE3NVV JOHN 
VE3FGK DAVE 
VE3IUV RON 
VE3SP RON 


LLLS 


00100 
00110 
00120 
00130 
00140 
00150 
00160 
00170 
00180 
00190 
00200 
00210 
00220 
00230 
00240 
00250 
00260 
00270 
00280 
00290 
00300 
00310 
00320 
00330 
00340 
00350 
00360 
00370 
00380 
00390 
00400 
00410 
00420 
00430 
00440 
00450 
00460 
00470 
00480 
00490 
00500 
00510 
00520 
00530 
00540 
00550 
00560 
00570 
00580 
00590 
00600 
00610 
00620 
00630 
00640 
00650 
00660 
00670 
00680 


; AUTO DISK I/O SUBROUTINES FOR VOLUME 3 


FIGURE 1 


s SYNCHRONOUS PACKET RADIO USING THE SOFTWARE APPROACH 


3 FOR TRSDOS 2.3 = 


3 SOURCE # AUTO 1 


3 COPYRIGHT 


SETUP 
LENGTH 
AUTSAV 
CONREQ 
BEFORE 
SEGNUM 
CLRHY 
SEND34 
PACK 
FRAMES 
MOVDN 
SIGN9 
MENU 


FCB 
BUFFER 
CHEKIT 


TESTL 


TESTH 


EQU 
EKQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
KQU 


29760 
75FBH 
75FDH 
75FEH 
7601H 
7603H 
7604H 
7607H 
760AH 
7611H 
761FH 
762FH 
7630H 
49632 


Z,TESTH 
'S! 
Z, TESTS 


HL 
A, (HL) 
ue ey 


NZ 
(SIGN9) ,A 


NEWDOS PLUS 


= NEWDOS80 1.0 


OBJECT # AUTO 2 


1984 BY RICHCRAFT ENGINEERING LTD. 


sINITIALIZE PGM POINTERS 
;INFO FIELD LENGTH/FRAME 
sAUTO SAVE DISK POINTER 
:;SABM POINTER 

:END RCVD INFO III-MEMORY 
sVERY LONG FILE SEGMENTS 
s:CLEAR HI-MEMORY 

:XMIT MESSAGE ADDRESS 
sXMIT MULTI-FRAME ADDRESS 
sNUMBER OF FRAMES/PACK 
:RESTORE DOS FM MID-MEM 
*TYPE FUNCTION AUTO PTR 
sDISPLAY MAIN MENU 

sDISK FILE CONTROL BLOCK 
;SAVE 32 BYTES FOR FCB 
sDISK I/O WORKING SPACE 
sTEST 

sTHE 

sAUTO 

3 FUNCTION 

;DESIRED 

:BY 

;THE 

sSTATION 

;WHO 

sCONNECTED 

3;TO 

3 YOUR 

sSTATION 

sWHICH 

:IS 

s NOW 

; IN 

sTHE 

:AUTO 

3: MODE, 

:GOT A 'LIST' COMMAND ? 
:IF SO, 

sTHEN SET SIGN9 FOR LIST 
sRETURN WHENCE U CAME +I 
;LAST LETTER WAS AN ‘'H! 


00690 
00700 
00710 
00720 
00730 
00740 
00750 TESTS 
00760 
00770 
00780 
00790 
00800 
00810 
00820 TESTA 
00830 
00840 
00850 
00860 
00870 
00880 
00890 
00900 
00910 
00920 
00930 
00940 
00950 
00960 
00970 
00880 
00990 TESTE 
01000 
01010 
01020 
01030 
01040 
01050 
01060 
01070 
01080 
01090 
01100 
01110 
01120 
01130 
01140 
01150 
01160 DIZ 
01170 
01180 
01190 
01200 
01210 
01220 DZ 
01230 
01240 
01250 
61260 FINISH 
01270 CLS 


A, (HL) 
tp? 

NZ 

A,2 
(SIGN) ,A 


HL 

A, (HL) 
‘A’ 
Z,TESTA 
ha 
Z,TESTE 


A,6 
(SIGN9) ,A 
(SAVEIT) ,HL 


(SIGN9) ,A 
(SAVEIT) , HL 


A, (HL) 

0 
Z,FINISH 
033H 


3 COMMAND 

sWAS IT 'HELP' ? 

;IF NOT, IGNORE IT 

;IF SO, 

:THEN SET SIGN9 FOR HELP 
;RETURN WHENCE U CAME +1 
sLAST LETTER WAS AN 'S' 
3;TEST FOR 

>'A' AS IN SAVE 

3IF SO, TEST FOR 'V' 
sELSE TEST FOR 'E' AS IN 
:SEND. IF SO, TEST 'N' 
sRETURN WHENCE U CAME +1 
:GOT AN 'S' AND 'A'! 

: NOW 

sTEST 

7FOR 

;A ‘vt 

AND 

s'E? 

sIF so, 

sALSO TEST 

:FOR A 

:SPACE AFTER SAVE 

3IF NOT, 

THEN IGNORE IT 

s ELSE 

SET SIGNS FOR 'SAVE' 
3AND SAVE MEM LOCATION 
:FOR 'SAVE' FILE NAME 
3;GOT AN 'S' AND ‘'E! 

7SO 

3:TEST 

sFOR 

s'n’ 


¢ 

:SPACE ? 

; IF 

3SO ? 

sTHEN SET 

SIGNS FOR A 'SEND' 

sAND SAVE MEM LOCATION 
:FOR SEND FILE NAME 
sDISPLAY 

:A MESSAGE 

3;ON VIDEO 

3AT CURSOR 

sLOCATION WITH 

3ZERO DELIMITER 

;MOVE HL TO ACCUM 
:CONVERT ACCUM TO STRING 
;DISPLAY IT ON VIDEO 
s;RETURN WHENCE U CAME +1 
RETURN WHENCE U CAME +1 
3C LEAR VIDEO 


ra > 


01280 
01290 
01300 
01310 
01320 
01330 
01340 
01350 
01360 
01370 
01380 
01390 
01400 
01410 
01420 
01430 
01440 
01450 
01460 
01470 
01480 
01490 
01500 
01510 
01520 
01530 
01540 
01550 
01560 
01570 
01580 
01590 
01600 
01610 
01620 
01630 
01640 
01650 
01660 
01670 
01680 
01690 
01700 
01710 
01720 
01730 
01740 
01750 
01760 
01770 
01780 
01790 
01800 
01810 
01820 
01830 
01840 
01850 
01860 


ERR 


TESTSP 


INPNAM 


INNAME 


ESCAPE 


LONG 
LON1 


(16416) ,HL 
DE, 15361 
BC, 1023 
(HL) ,32 


'SP ERROR ° 
0 

HL,9 
HL,SP 
DE, 29756 
18H 

Zz 

HL 

CLS 

HL, ERR 
Diz 

HL 

DZ 

049H 
SP,29758 
MENU 

CLS 

HL, NAM1 
DIZ 

049H 

1 
Z,ESCAPE 
CLS 
HL,NAM1A 
DIZ 
1BB3H 
10H 
1E5AH 
DE, HL 
(DUMP+1) , HL 


(HOWFAR+1) , HL 


CLS 

HL ,NAM2 
DIZ 
1BB3H 
HL,41E8H 
a, (HL) 

0 
Z,ESCAPE 
LONG 

HL, 41E8H 
DE,FCB 


DRIVE 


AF 
HL, 53248 


(DUMP+1) ,HL 
(HOWFAR+1) , HL 


MENU 
BC ,0 
A, (HL) 
0 


;RESET VIDEO CURSOR 
sCLEAR THE 

31024 BYTE 

VIDEO DISPLAY 

3 WITH 

: SPACES 

;STACK POINTER 

sERROR MESSAGE 

;THE OPTIONAL 

3 STACK 

: POINTER 

:TEST 

3 IS INCLUDED 

FOR TROUBLE 

: SHOOTING 

; YOUR 

3 PROGRAM 

¢ MODIFICATIONS 

; SHOULD 

? YOU 

s WISH 

3TO USE IT. 

3;NOT USED BY AUTO MODE 
ONLY FOR KEYBOARD INPUT 
;REMEMBER DELIMITERS MSG? 
sAWAIT KEYBOARD INPUT 
BREAK KEY PRESSED ? 

sIF SO, GOTO MAIN MENU 
3s;C LEAR VIDEO 
BEGIN ADDRESS MESSAGE ? 
ON VIDEO 

: INPUT BEGIN ADDRESS 
SCAN STRING SET 'C' FLAG 
sCONVERT UNSIGNED INTEGER 
:SWAP INTO HL REGISTER 
LOAD BEGIN INTO DUMP 
:AND BEGIN INTO HOWFAR 
s;C L EA R VIDEO 
: INPUT FILE NAME MESSAGE? 
sON VIDEO 

: INPUT FILE NAME 

sWHERE STASHED IN MEMORY 
TEST FOR NOTHING INPUT 
;IF SO, 

:GOTO MAIN MENU 

;HOW MANY BYTES IN NAME? 
:NAME LOCATION IN MEMORY 
:SO MOVE THEM TO 

:FILE CONTROL BLOCK 

:AND DRIVE NUMBER TOO 
sRETURN WHENCE U CAME +1 
ADJUST STACK FOR CALL 
;RESET TO NORMAL 

:DUMP AND 

; HOWFAR 

;GOTO MAIN TIP MENU 

*HOW LONG IS FILE NAME ? 
s;BYTE FROM NAME STRING 
3ZERO DELIMITER 


01870 
01880 
01890 
01900 
01910 
01920 
01930 
01940 
01950 
01960 
01970 
01980 
01990 
02000 
02010 
02020 
02030 
02040 
02050 
02060 
02070 
02080 
02090 
02100 
02110 
02120 
02130 
02140 
02150 
02160 
02170 
02180 
02190 
02200 
02210 
02220 
02230 
02240 
02250 
02260 
02270 
02280 
02290 
02300 
02310 
02320 
02330 
02340 
02350 
02360 
02370 
02380 
02390 
02400 
02410 
02420 
02430 
02440 
02450 


LIST1 


GOON 
GOON1 


GOON2 


DUN 


TESDOS 


HOLE 
DUN1 


DUN2 


GOBAK 


ONWARD 


Zz 

C 

HL 
LON1 
0C440H 


A 
(SIGNS) A 
A,195 
(400CH) ,A 
MOVDN 

HL , GGON 
(4468H) ,HL 
CLS 


Z, TESDOS 
033H 

HL 

13 

NZ ,GOON1 
HL 


HL 
(HOLE) ,A 
HL 

A, (HL) 


'Q! 
NZ ,DUN1 


Oo 


A, (HOLE) 
HL 

GOON2 

HL, (16416) 
HL 


P, ONWARD 
HL 
GOBAK 

HL 

HL 
DE,HL 


sRETURN WITH BYTE COUNT 
31 MORE BYTE 

sNEXT MEM LOCATION 

;GO COUNT IT 

;LIST SUBROUTINE LOCATION 
3ZERO OUT LIST POINTER 
:AT BEGIN RECEIVE MODE 
s;RESTORE JUMP 

IN LOW MEMORY 
sRESTORE DOS 
sCOMPOSITE DIRECTORY SUB= 
sROUTINE SEARCH ADDRESS 
:FOR TRSDOS 2.3 AND 
sNEWDOS + AND 

:NEWDOS 1.0 
sCOMPATIBILITY 
sDISPLAY DIRECTORY VIDEO 
sSINCE 

;TRSDOS 2.3 

3; AND 

s;NEWDOS + 

;AND 

sNEWDOS 1.0 

3; USE 

s SOMEWHAT 

;DIFFERENT 

3;LIST THE 

sDIRECTORY 
;SUBROUTINES, 

;THIS 

:SIMPLE 

: PROGRAM 

;FINESSES 

sTHE 

3; PROBLEM 

3 BY 

3FIRST 

sDISPLAYING 

3 THE 

; DIRECTORY 

sON 

:; VIDEO. 

7;THEN, 

3 THE 

: LENGTH 

3;0F 

: THE 

;DIRECTORY 

3 ON 

THE 

3 VIDEO 

; DISPLAY 

2IS 

;CALCULATED 

: USING 

3 THE 

3* DOS 

3; READY 

;MESSAGE, 


ELLE 


02460 
02470 
02480 
02490 
02500 
O29 10 
0252.0 
02530 
02540 
02550 
02560 
O29 20 
02580 
02590 
02600 
02610 
02620 
02630 
02640 
02650 
02660 
02670 
02690 
02690 
02700 
02710 
02720 
02730 
02740 
02750 
02760 
02770 
02780 
02790 
02800 
02810 
02820 
02830 
02840 
02850 
02860 
02870 
02880 
02890 
02900 
029 10 
02920 
02930 
02940 
02950 
02960 
02.970 
02980 
02990 
03000 
03010 
03020 
03030 
03040 


LBYTES 
CLRLO 


NUMB 
MOVHI 1 


MOV 1 


STORDE 


THEND 
LFEED 


NUM2 
CALF RM 


HL, 15360 
OBC7H 
(LBYTES) ,HL 
HL 

BC , 32000 
060H 

BC 

HL, 15360 
DE, 93248 


SP,29758 
SETUP 
CLS 
CLRLO 
MOVHI1 
CALF RM 
PACK 

0 

HL, 16872 
DE, 16873 
BC,12878 
(HL) ,0 


0 

A, 62 
(NUMB) ,A 
HL,53248 
DE, 17408 
BC, (LBYTES) 
A, (HL) 
(DE) ,A 
HL 

DE 

A, (NUMB) 
A 
(NUMB) ,A 
Z,LFEED 
BC 

A,B 

Cc 

Z, STORDE 
MOV1 
READY 
(THEND) ,DE 


0 

A, 62 
(NUMB) ,A 
A,13 
(DE) ,A 
DE 

A,10 
(DE) ,A 
DE 


0 
DE, (THEND) 
HL, 17408 


; AND 

3 THE 

sDISK 

3 DIRECTORY 

3; MOVED 

sFROM VIDEO 

TO 

3 HI-MEMORY 

; RIGHT 

: HERE. 

sRESET STACK POINTER 

s INITIALIZE PGM POINTERS 
7CL & AR VIDEO 
sCLEARK OUT DOS LO-MEM 
3MOVE FROM HI TO LO=-MEM 
CALCULATE FRAMES /PACK 
:AND GO SEND THEM. 
sNUMBER BYTES READ STASH 
;CLEAR OUT DOS 

: FROM 

3sLOW MEMORY 

sAND REPLACE 

; WITH 

3 ZEROS. 

sBYTES PER LINE STASH 
;USE 62 PER LINE 

; AND SET NUMB 

sBEGIN HI-MEMORY 

sBEGIN MULTI-FRAME XMIT 
sNUMBER BYTES TO MOVE 
;BYTE FROM HI-MEM 

sMOVE TO LO-MEM 

sNEXT HI-MEM LOCATION 
sNEXT LO-MEM LOCATION 
sBYTES PER LINE 

:MINUS ONE 

sAND SAVE IT 

ZERO DO CARRET/LINEFEED 
sBYTES TO MOVE COUNTER 
sTEST 

;FOR ZERO ? 

sSAVE END LOCATION LO-MEM 
sELSE MOVE NEXT ONE 
7<READY> MSG ON THE END 
sSAVE END LO-MEM LOCATION 
3;RETURN WHENCE U CAME +1 
sEND LOCATION STASH 
:BYTES PER LINE 

:RESET COUNTER 

sCARRIAGE RETURN 

;STUFF INTO LO-MEM 

sNEXT LO-MEM LOCATION 
s;LINE FEED 

3;STUFF INTO LO-MEM 

sNEXT LO=MEM LOCATION 
;RETURN WHENCE U CAME +1 
sNUMBER FRAMES COUNTER 
:LO-MEM END MSG LOCATION 
sBEGIN MULTI-FRAME ADRESS 


03050 
03060 
03070 
03080 
03090 
03100 
03110 NUM1 
03120 
03130 
03140 
03150 
03160 
03170 
03180 
03190 
03200 FIN 
03210 
03220 
03230 
03240 
03250 SET7 
03260 
03270 
03280 SET1 
03290 
03300 
03310 
03320 HELP1 
03330 
03340 
03350 
03360 
03370 
03380 
03390 
03400 
03410 
03420 
03430 
03440 
03450 
03460 
03470 
03480 
03490 
03500 
03510 


03520 HELPIA 


03530 
03540 OPEN1 
03550 
03560 
03570 
03580 
03590 


03600 MULPLY 


03610 
03620 
03630 MULO 


OBC7H 
DE, 250 
1C90H 

C, SET] 

A 
(NUM2) ,A 
DE, (LENGTH) 
A 

HL,DE 

A, (NUM2) 
A 
(NUM2) ,A 
Z,FIN 

C, FIN 
NuM1 

A, (NUM2) 
7 


PyoLl? 
(FRAMES) ,A 


A,7 
(FRAMES) ,A 


A,1 
(FRAMES) ,A 


0c580H 
A 
(SIGN9),A 
A,195 
(400CH) ,A 
MOVDN 
HL,HELP1A 
§, FCB 
BC,7 


OPEN1 
MULPLY 
READ 
CLOSE 
SP,29758 
SETUP 
CLRLO 
MOVHT2 
CALFRM 
CLRHY 
PACK 
'HELP: 1' 
13 

DE, FCB 
HL,BUFFER 
B,0 
4424H 
NZ, ERROR 


A, (FCB+12) 
47 

P, VYLONG 
HL,0 


:SUBTRACT HL FROM DE 
7250 BYTES ? 

COMPARE HL ~ DE 

:< 250 SO SET 1 FRAME 

3; ELSE 

:RESET COUNTER 

sINFO FIELD LENGTH/PACK 
CLEAR CARRY FLAG 
sSUBTRACT DE FROM HL 
:FRAME COUNTER 

sPLUS ONE 

sAND SAVE IT 

;IF ZERO ALL DONE 
TUPURRKY Aly DONE 

ELSE DO NEXT ONE 
FRAMES COUNT 

37 FRAMES ? 

:MORE THAN 7, SET AT 7 
;ELSE SET AT NUMBER 
;RETURN WHENCE U CAME +41 
sFRAMES/PACK = 7 

3;SET FRAME COUNTER 
;RETURN WHENCE U CAME +1 
sFRAMES/PACK = 1 

sSET FRAME COUNTER 
;RETURN WHENCE U CAME +1 
HELP MESSAGE SUBROUTINE 
3;ZERO OUT HELP POINTER 
;AT BEGIN RECEIVE MODS 
;RESTORE JUMP 

:IN LOW MEMORY 

:RESTORE DOS LO-MEM 
sHELP:1 DISK FILE NAME 
sFILE CONTROL BLOCK 
:FILE NAME + DELIMITER 
sMOVE TO FCB 

sOPEN AN EXISTING FILE 
:CALCULATE BYTES IN FILE 
:READ THEM FROM DISK 
sCLOSE THE DISK FILE 
RESET STACK POINTER 

; INITIALIZE PGM POINTERS 
;CLEAROUT DOS FROM LO=-MEM 
;MOVE FILLE Hi TO LO-MEN 
sCALCULATE FRAMES/PACK 
CLEAR OUT HI-MEM 

7SEND MULTI-FRAME PACK 
sHELP FILE NAME AND DPIVE 
7FCB DELIMITER 

:OPEN AN EXISTING FILE 
:DISK I/O BUFFER ADDRESS 
:BYTES PER SECTOR 

;DOS OPEN IT SUBROUTINE 
:Z% FLAG SET IF ERROR 
sRETURN WHENCE U CAME +1 
;NUMBER RECCRDS IN FILE 
:;MORE THAN 47 ? 

;IF SO, GOTO VERY LONG 
:BYTES IN FILE COUNTER 


vLL'S 


03640 MUL 
03650 
03660 
03670 
03680 
03690 MUL2 
03700 
03710 
03720 
03730 MuL3 
03740 
03750 
03760 
03770 
03780 READ 
03790 
03800 LG 
03810 
03820 
03830 
03840 
03850 
03860 
03870 LONGI 
03880 
03890 
03900 
03910 
03920 
03930 
03940 CLOSE 
03950 
03960 
03970 
039 80 
03990 
04000 
04010 
04020 
04030 ERROR 
04040 
04050 
04060 
04070 
04080 
04090 ER! 
04100 
04110 
04120 
04130 
04140 
04150 
04160 ER2 
04170 
04380 
04190 
04200 
04210 
04220 


MUL 

A, (FCB+8) 
E,A 

HL, DE 
(LBYTES) ,HL 
DE, 53248 


HL, DE 
(LONG1+1) , HL 


HL, 53248 
DE,FCB 


HL ,DE 


AF 

HL, 53248 
(DUMP+1) ,HL 
(HOWPAR+1) , HL 
AF 

2 

HL 

H,0 

L,A 

OASAH 
OA7FH 

OFBDH 
DE,MS2A 

A, (HL) 


0 
Z,ER2 
(DE) ,A 
HL 

DE 

ER1 
CLS 

AF 
SETUP 
CLRLO 
CLRHY 
TY ,»MS2C 
SEND32 


sBYTES PER SECTOR IN FILE 
3sADD TO BYTE COUNTER 
sMINUS ONE RECORD 

:IF ZERO, DO LAST ONE 
sADD UP NEXT ONE 

sBYTES IN LAST SECTOR 
sSWAP IN TO ‘'E! 


3ZERO OUT 'D' 


sADD TO TOTAL BYTES 

:AND SAVE THEM HERE 
¢BEGIN HI-MEM LOCATION 
sHL+DE IN END LOCATION 
sAND SAVE THEM HERE 
sRETURN WHENCE U CAME +1 
;WHERE TO PUT FILE IN MEM 
sFILE CTRL BLOCK ADDRESS 
3;SAVE MEM LOCATION STACK 
READ BYTE FROM DISK FILE 
;RESTORE MEM LOCATION 
sDISK BYTE INTO MEMORY 
sNEXT MEM LOCATION 

;SAVE IT ON STACK 

SAVE FCB POINTER 

;MEM END ADDRESS OF FILE 
7CLEAR CARRY FLAG 
SUBTRACT DE FROM HL 
;RESTORE FCB POINTER 
RESTORE MEM LOCATION 
;RETURN IF ALL DONE 

;READ NEXT DISK FILE BYTE 
3FCB MEM LOCATION 

sCLOSE FILE SUBROUTINE 
sSAVE FLAG ON STACK 


sBEGIN HI-MEM 
sRESET DUMP 

;RESET HOWFAR 
sRESTORE FLAG 


ADDRESS 


;RETURN UNLESS ERROR 


sADJUST STACK 
:ZERO OUT ‘'H' 


FOR CALL 


sERROR NUMBER TO 'L® 
MOVE HL INTO ACCUM 


;MAKE SURE AN 


INTEGER 


sCONVERT ACCUM TO STRING 
s;ERROR MESSAGE IN MEM 
;FIRST ERROR NUMBER 
ZERO DELIMITER 

;ALL DONE ? GOTO ER2 


ERROR NUMBER 
;NEXT ERROR # 
gNEXT MESSAGE 
GO MOVE NEXT 
7;C LEAR 

s;ADJUST STACK 


TO MESSAGE 
LOCATION 
LOCATION 
ONE 
VIDEO 
FOR CALL 


sINITIALIZE PGM POINTERS 
:CLEAR OUT DOS LO=-MEM 


sCLEAR OUT HI- 


MEM 


s;ERROR # MESSAGE 


:TRANSMIT ERROR # MESSAGE 


04230 MOVH12 
04240 
04250 
04260 
04270 
04280 
04290 
04300 
04310 


04370 SEND1 


04420 SEN1 


04490 SEN2 


04660 DRIVE 


04800 SAVEIT 
04810 NAM% 


HL, 53248 
DE, 17408 
BC, (LBYTES) 


(THEND) ,DE 


0C680H 

A 
(SIGNS) ,A 
HL, (SAVEIT) 


A,195 
(400CH) ,A 
MOVDN 
OPEN1 
MULPLY 
READ 
CLOSE 
SP,29758 
SETUP 
CLRLO 
MOVHI2 
CALFRM 
CLRHY 
CLS 
PACK 
Apts * 
(DE) ,A 
(BC) ,A 
DE 

BC 
A,‘1' 
(DE) ,A 
(BC) ,A 
DE 


0 


sMOVE H-MEM TO LO-MEM 
:WITHOUT CARRET/LINEFEEDS 
sNUMBER OF BYTES TO MOVE 
3;bDO IT 

3 MULTI-FRAME 

: TRANSMIT 

3 SUBROUTINE 

3 USES 

3 THREE 

sEACH 128 

3 DELIMTERS 

3IN A ROW 

RETURN WHENCE U CAME +1 
sAUTO SEND FILE ROUTINE 
3$ZERO OUT SEND POINTER 
;AT BEGIN RECEIVE MODE 
sFILE NAME MEM LOCATION 
FILE CTRL BLOCK ADDRESS 
:ZERO OUT 'BC' 

:MOVE FILE NAME TO FCB 
CARRIAGE RETURN DELIMTER 
;GOTO SEN2 IF DONE 

3LOAD NAME INTO FCB 
sNEXT MEM LOCATION 

sNEXT FCB LOCATION 

3GO MOVE NEXT ONE 

:STUFF DRIVE # IN FCB 
sCLEAR OUT HI-MEM 
sRESET JUMP 

3IN LO-MEM 

RESTORE DOS TO LO-ME!? 
OPEN AN EXISTING FILE 
sCALCULATE # FILE BYTES 
READ THEM FROM DISK 
3;THEN CLOSE THE FILE 
sRESET STACK POINTER 

s INITIALIZE PGM POINTERS 
3CLEAR OUT DOS LO=MEM 
¢:MOVE FILE HI TO LO=MEM 
sCALCULATE FRAMES/PACK 
:CLEAR OUT HI-MEM 

3;C LEAR VID E-:0 
¢SEND MULTI-FRAME/PACKS 
sDRIVE # SEPARATOR 
sSTUFF INTO FCB 

gNOT USED NOW 

sNEXT FCB LOCATION 

3;NOT USED NOW 

7DISK NUMBER 

3;STUFF INTO FCB 

sNOT USED NOW 

sNEXT FCB LOCATION 

sNOT USED NOW 

FILE NAME DELIMITER 
3;STUFF INTO FCB 

sNOT USED NOW 

sRETURN WHENCE U CAME +14 
sFILE NAME BEGIN STASH 


"INPUT FILE NAME ° 


GLLS 


04820 
04830 
04840 
04850 
04860 
04870 
04880 
04890 
04900 
04910 
04920 
04930 
04940 
04950 
04960 
04970 
04980 
04990 
05000 
05010 
05020 
05030 
05040 
05050 
05060 
05070 
05080 
05090 
05100 
05110 
05120 
05130 
05140 
05150 
05160 
05170 
05180 
05190 
05200 
05210 
05220 
05230 
05240 
05290 
05260 
05270 
05280 
05290 
05300 
05310 
05320 
05330 
05340 
0539.0 
05360 
05370 
05380 
05390 
05400 


SAVE 1 


SAV1 


SAV2 


OFEN2 


OPEN3 


OPEN4 


SENDIT 


SAV3 


0 

0c700H 

A 

(SIGN9) ,A 
CLS 

A.195 
(400CH) ,A 
MOVDN 

HL, (SAVEIT) 


SENDIT 


44244h 

NZ ,OPEN4 
SP, 29758 
SETUP 

TY ,MS2B 
SEND3Z 
HL, BUFFER 


C.10H 
4420H 


CLRHY 

A,1 
(AUTSAV) ,A 
LY ,MS3A 
SEND3Z 
0C780H 
A,195 
(400CH) ,A 
MOVDN 
SETEND 
SETFCB 
OPEN1 
4448H 
DUMP 
CLOSE 

SP ,29758 
SETUP 


s;DELIMITER 

;AUTO SAVE DISK FILE 
;ZERO OUT SAVE POINTER 
3AT BEGIN RECEIVE MODE 
:C LEAR VIDEO 
;RESTORE JUMP 

;TO LOW-MEM 

sRESTORE DOS TO LO=-MEM 
;BEGIN FILE NAME LOCATION 
:FILE CTRL BLOCK ADDRESS 
:;FILE NAME TEMP. STASH 
:FILE NAME BYTE 

*FILE NAME DELIMITER 
sGOTO SAV2 IF DONE 

;NAME BYTE TO FCB 
sTEMPORARY STASH 

:NEXT NAME BYTE LOCATION 
;NEXT FCB LOCATION 

:NEXT STASH LOCATION 
sCONTINUE MOVING NAME 
;LOAD DISK DRIVE NUMBER 
;OPEN NEW FILE ONLY 

; RESET STACK POINTER 

: INITIALIZE PGM POINTERS 
sCLEAR OUT DOS LO-MEM 
sSEND 'GO AHEAD' MESSAGE 
DISK I/O WORKING AREA 
*FILE CTPL BLOCK ADDRESS 
2256 BYTES PER RECORD 
s;FILE TYPE DOURTFUL 
OPEN AN EXISTING FILE 
:NZ = IT DOES NOT EXIST 
3;NO DUPLICATION ALLOWED 
:SO RESET SP & INTXALIZE 
:;NAME ALREADY USED MSG 
:;SEND 'TRY ANOTHER' MSG 
sDISK I/O WORKING AREA 
s;FILE CTRL BLOCK ADDDRESS 
3256 BYTES PER RECORD 
FILE TYPE DOUBTFUL 
sOPEN A NEW DISK FILE 
sRETURN WHENCE U CAME +1 
CLEAR HI-MEM 

; SET 

;AUTO SAVE FILE POINTER 
:'GO AHEAD' MESSAGE 
:SENT VIA SEND3 

:;AUTO SAVE HI-MEM ONLY 
*FOR FILES > 12K BYTES 
sLENGTH 'IF' A DISCONNECT 
»= ALL DONE IS RECEIVED. 
:STUFF 3 128 DELIMITERS 
;MOVE FILE NAME INTO FCB 
sOPEN AN EXISTING FILE 
sPOSITION END OF FILE 
;WRITE MEM TO DISK 
sCLOSE THE DISK FILE 

: RESET STACK POINTER 

s INITIALIZE PGM POINTERS 


05410 
05420 
05430 
05440 SETEND 
05450 
05460 
05470 
05480 
05490 
05500 
05510 
05520 
05530 
05540 HOWFAR 
05550 FAR1 
05560 
05570 
05580 
05590 
05600 
05610 
05620 
05630 
05640 
05650 
05660 
05670 
05680 
05690 
05700 DUMP 
05710 
05720 DUM1 
05730 
05740 
05750 
05760 
05770 
05780 
05790 
05800 SOFAR 
05810 
05820 
05830 
05840 
05850 
05860 
05870 NAM1 


DEFM 


CAPE ELSE <ENTER>' 


05880 
05890 SETFCB 
05900 
05910 ST1 
05920 
05930 
05940 
05950 
05960 
05970 
05980 


DEFB 
LD 
LD 
LD 
LD 
CP 
RET 
INC 
INC 
JP 
ORG 


CLRLO 
CLRHY 
CONREQ 

HL, (BEFORE) 
A,128 


(SOFAR+1) , HL 
HL, 53248 


(SOFAR+1) ,HL 


HL , 53248 
DE, FCB 
A, (HL) 
HL 

1BH 

HL 
NZ,ERROR 
HL 

HL 

DE 

DE, 65535 
A 

HL ,DE 

DE 

HL 

Z 

DUM1 


s;CLEAR OUT DOS LO=-MEM 
CLEAR HI-MEM 
;RE-CONNECT TO STATION 
:END HI-MEM INFO FIELDS 
STUFF 

3 EACH 

;END OF MESSAGE 
;DELIMITERS 

sAT 

THE 

3; VERY END. 

;SAVE END MEM LOCATION 
RETURN WHENCE U CAME +1 
s;CALCULATE BYTES TO SAVE 
;TO DISK FILE 

: LOOK 

:FOR 

3; THREE 

: EACH 

sDECIMAL 

3128 

sEND 

; OF 

: MESSAGE 

:DELIMITERS 

sINA 

sROW. 

*SAVE LOCATION IN SOFAR 
¢RETURN WHENCE U CAME +1 
BEGIN HI-MEM INFO FIELDS 
FILE CTRL BLOCK ADDRESS 
sBYTE TO SAVE ON DISK 
;SAVE BYTE MEM LOCATION 
;WRITE BYTE TO DISK 
sRESTORE BYTE LOCATION 
;Z FLAG SET IF ERROR 
:NEXT BYTE MEM LOCATION 
s;SAVE IT IN STACK 

;SAVE FCB POINTER 

LAST MEM BYTE LOCATION 
s;CLEAR CARRY FLAG 

: SUBTRACT DE FROM HL 
sRESTORE FCB POINTER 
;AND NEXT MEM LOCATION 
;RETURN IF ALL DONE 

:GO DUMP NEXT ONE TO DISK 


"REMEMBER 128 DELIMITERS ? HIT BREAK TO ES 


0 

HL, NAME1 
DE, FCB 
A, (HL) 
(DE) ,A 
13 

Z 

HL 

DE 

ST1 
0C840H 


;DELIMITER 

;FILE NAME TEMP. STASH 
;FILE CTRL BLOCK ADDRESS 
;MOVE FILE NAME+DELIMITER 
:TO FILE CTRL BLOCK 
;DELIMITER ? 

:IF SO, ALL DONE 

sNEXT NAME LOCATION 
;NEXT FCB LOCATION 

;MOVE NEXT ONE 

;MANUAL SAVE DISK FILE 


OLL Se 


05990 SVFILE CALL 


06000 CALL 
06010 LD 
06020 LD 
06030 CALL 
06040 CALL 
06050 CALL 
06060 CALL 
06070 LD 
06080 CALL 
06090 CALL 
06100 JP 
06110 MS2C DEFB 
06120 DEFB 
06130 DEFM 
06140 MS2A DEFM 
06150 DEFB 
06160 DEFB 
06170 DEFB 
06180 DEFB 
06190 ORG 
06200 LDFILE CALL 
06210 CALL 
06220 LD 
06230 LD 
06240 CALL 
06250 CALL 
06260 CALL 
06270 CALL 
06280 LD 
06290 CALL 
06300 LD 
06310 CALL 
06320 CALL 
06330 CALL 
06340 JP 


06350 HIHL DEFW 
06360 BAKUP LD 
06370 BAK1 DEC 


06380 LD 
06390 cP 
06400 JP 
06410 CP 
06420 JP 
06430 INC 
06440 LD 
06450 RET 
06460 TESAGN DEC 
06470 LD 
06480 CP 
06490 JP 
06500 DEC 
06510 LD 
06520 CP 
06530 JP 
06540 LD 
06550 RET 
06560 ORG 


06570 SAVMSG XOR 


INPNAM 
HOWFAR 
A,195 
(400CH) ,A 
MOVDN 
OPEN3 
DUMP 
CLOSE 

SP ,29758 
SETUP 
CLRLO 
MENU 

13 

10 

‘ERROR # § 


: <READY> $ 


13 
10 

128 

128 
0C880H 
INNAME 
CLRHY 
A,195 
(400CH) ,A 
MOVDN 
OPEN1 
MULPLY 
READ 
(HIHL) , HL 
CLOSE 
SP,29758 
SETUP 
CLRLO 
BAKUP 
MENU 

0 

HL, (HIHL) 


128 
Z,TESAGN 


HL 
(BEFORE) ,HL 


HL 

A, (HL) 

128 

NZ,BAK1 

HL 

A, (HL) 

128 

NZ,BAK1 
(BEFORE) ,HL 


0C900H 
A 


;REMINDER+INPUT FILE NAME 
s;CALCULATE BYTES TO SAVE 
;RESTORE JUMP 

3;TO LO-MEM 

sRESTORE DOS TO LO-MEM 
sOPEN A NEW FILE 

sDUMP HI-MEM TO DISK 
sCLOSE THE DISK FILE 
RESET STACK POINTER 
sgINITIALIZE PGM POINTERS 
sCLEAR DOS OUT LO-MEM 
;MAIN MENU FOR INSTRUCTS 
sCARRIAGE RETURN 

sLINE FEED 

sERROR MESSAGE 

gERROR # + <READY> MSG 
sCARRIAGE RETURN 

sLINE FEED 

sONLY 2 DELIMITERS NEEDED 
FOR SEND3 PROCESSING 
;MANUAL LOAD FILE TO MEM 
gs INPUT FILE NAME 

sCLEAR HI-MEM 

sRESTORE JUMP 

sTO LO-MEM 

sRESTORE DOS LO-MEM 
OPEN EXISTING DISK FILE 
s;CALCULATE FILE LENGTH 
sLOAD FILE TO HI-MEM 
;SAVE HI-MEM END LOCATION 
sCLOSE DISK FILE 

;RESET STACK POINTER 

s: INITIALIZE PGM POINTERS 
;CLEAR OUT DOS LO-MEM 
sCHECK TOO LONG LOADED ? 
¢MENU FOR INSTRUCTIONS 
sEND HI-MEM FILE LOCATION 
sIF THE FILE LENGTH JUST 
3 LOADED 

:HAD RECORDS 

sLESS THAN 

$ 256 BYTES 

3;LONG, 

sTHEN 

; OBVIOUSLY 

s;THIS 

3 SIMPLE 

3 SUBROUTINE 

sWILL 

3 LOAD 

FAR 

3TOO 

3 MANY 

¢BYTES FROM DISK TO MEM. 
:BAKUP'S JOB IS TO TRY & 
:CORRECT THIS SITUATION. 
:RETURN WHENCE U CAME +1 
sAFTER SAVE IN AUTO MODE 
ZERO OUT 


06580 LD 
06590 LD 
06600 JP 
06610 MS4A DEFB 
06620 DEFB 
06630 DEFM 
DISK. IF YOU WISH‘ 
06640 DEFB 
06650 DEFB 
06660 DEFM 
ND. <READY> ' 
06670 DEFB 
06680 DEFB 
06690 DEFB 
06700 DEFB 
06710 READY LD 
06720 LD 
06730 LDIR 
06740 RET 
06750 MS5SA DEFB 
06760 DEFB 
06770 DEFM 
06780 DEFB 
06790 DEFB 
06800 DEFB 
06810 DEFB 
06820 DEFB 
06830 RET 
06840 MSTA DEFM 
06850 DEFB 
06860 DEFB 
06870 MS2B DEFB 
06880 DEFB 
06890 DEFM 
06900 DEFB 
06910 DEFB 
06920 DEFB 
06930 DEFB 
06940 NAME1 DEFS 
06950 MS3A DEFB 
06960 DEFB 
06970 DEFM 
O CLOSE FILE. ' 
06980 DEFB 
06990 DEFB 
07000 DEFB 
07010 DEFB 
07020 ORG 
07030 SAV4 LD 
07040 LD 
07050 CALL 
07060 LD 
07070 LD 
07080 CALL 
07090 CALL 
07100 CALL 
oe ela CALL 
07120 CALL 
07130 LD 


(AUTSAV) ,A 
IY,MS4A 
SEND3Z 

13 

10 


:AUTO SAVE POINTER 

;HAS BEEN SAVED MESSAGE 
;TRANSMIT VIA SEND3 
s;CARRIAGE RETURN 

7LINE FEED 


‘YOUR FILE HAS BEEN AUTOMATICALLY SAVED ON 


3 
10 


‘TO TEST IT TRY 


13 

10 

128 

128 
HL,MSSA 
BC, 14 


10 


;CARRIAGE RETURN 
;LINE FEED 
THE SEND (FILE NAME) COMMA 


CARRIAGE RETURN 

;LINE FEED 

;SEND 3 ONLY REQUIRES TWO 
128 DELIMITERS 
?<READY> MESSAGE 

;BYTES TO MOVE 

;MOVE IT INTO ‘DE! 
RETURN WHENCE U CAME +1 
sCARRIAGE RETURN 

LINE FEED 

:MESSAGE 

CARRIAGE RETURN 

;LINE FEED 

33 DELIMITERS 

sARE NEEDED 

3BY THE MULTI-FRAME 
;XMIT LO-MEM SUBROUTINE 
;DISK DRIVE NUMBER USED 
;USED. CHANGE TO SUIT 
sYOUR FANCY. 

;CARRIAGE RETURN 

;LINE FEED 


‘FILE NAME EXTANT ~ TRY ANOTHER ONE. ! 


13 
10 
128 
128 
13 
13 
10 


‘SEND DISK FILE 


13 

10 

128 

128 

OCA40H 
A,195 
(400CH) ,A 
MOVDN 

HL, (BEFORE) 


(SOFAR+1) , HL 


SETFCB 
OPEN1 
4448H 
DUMP 
CLOSE 
SP,29758 


#;CARRIAGE RETURN 

;LINE FEED 

;DELIMITER 

;DELIMITER 

713 BYTE FILE NAME STASH 
sCARRIAGE RETURN 

?;LINE FEED 

& WHEN DONE A DISCONNECT T 


;CARRIAGE RETURN 

;LINE FEED 

;DELIMITER 

;DELIMITER 

s;SAVE VERY LONG FILES 
;AFTER A 'WAIT' RNR HAS 
;HAS BEEN TRANSMITTED. 
RESTORE DOS TO LO=MEM 
?END HI-MEM INFO FIELDS 
;LOAD INTO SOFAR 

;SET FILE CTRL BLOCK 
;OPEN AN EXISTING FILE 
;POSITION TO END OF FILE 
sAND DUMP DATA TO DISK 
sCLOSE DISK FILE 

#RESET STACK POINTER 


LZELLS 


CALI 
CALE 
LD 
JP 

MS6A DEFB 
DEFB 
DEFM 
DEFB 
DEFB 
DEFB 
DEFB 

VYLONG LD 
LD 


vY1 SUB 


NUMSEC DEFB 
SECTOR DEFB 
NAMIA DEFM 


® 
DEFB 
ORG 
SEND2 CALL 
LD 
LD 
CALL 
CALL 
CALL 
CALL 
CALL 
LD 
CALL 
CALL 
CALL 
CALL 
CALL 
JP 


SETUP 
CLRHY 
IY ,MS6A 
SEND32Z 
i) 

10 


"<RNR CLEARED = 


13 

10 

128 
128 
(NUMSEC) ,A 
DE,0 
B,47 

B 
Z,DON2 
C,DON1 
D 


vY1 

D 

A,D 
(SEGNUM) ,A 
A 

E,A 

A 


B,47 

A,B 

E 

NZ ,DON3 
B,A 

A, (NUMSEC) 
B 


A 
(NUMSEC) ,A 
A,1 
(SECTOR) ,A 
HL, 12032 
MUL3 

0 

0 


s INITIALIZE PGM POINTERS 
;CLEAR HI-MEM 

:WAIT/RNR CLEARED MSG 
sCONTINUE SENDING MESSAGE 
sCARRIAGE RETURN 

;LINE FEED 

CONTINUE SENDING>' 
sCARRIAGE RETURN 

:LINE FEED 

sDELIMITER 

*DELIMITER 

sLOAD # OF' DISK SECTORS 
3ZERO OUT COUNTER 

sMAX SECTORS IN HI-MEM 
:SUBTRACT FROM TOTAL 

3Z FLAG SET = ALL DONE 

:C FLAG SET = ALL DONE 
sSEGMENT COUNTER 

TRY AGAIN 

: INCREMENT SEGMENT COUNT 
:SWAP I'JTO 'A' 

SAVE IN NUMBER SEGMENTS 
sDECREMENT SEGMENT COUNT 
sSWAP INTO 'E' 

$ZERO OUT 'A' 

:;MAX RECORDS PER SEGMENT 
7ADD ‘EM UP AGAIN 

sMINUS ONE FROM COUIJTER 
3NZ THEN DO IT AGAIN 
:;THEN SWAP INTO 'B' 
;NUMBER SECTORS REMAINING 
;SUBTRACT COUNTER 

sMINUS ONE 

:SAVE IT IN NUMBER SECTOR 
sONLY 1 

:SAVE IT IN SECTOR 

3;MAX SEGMENT LENGTH 

:AND GO SET LBYTCS TO MAX 
;NUMBER SECTORS STASH 
;SINGLE SECTOR STASH 


"INPUT BEGINNING MEM ADDRESS (53248 NOMINA 


0 

OCBOOH 
CLRHY 
A,195 
(400CH) ,A 
MOVDH 
OPEN1 
ANYMOR 
READ 
CLOSE 
SP,29758 
SETUP 
CLRLO 
MOVHI2 
CALFRM 
CLRHY 
PACK 


; DELIMITER 

sONLY USED FOR SENDING 
;DISK FILES GREATER THAN 
212K BYTES = 65K MAXIMUM, 
s;USED AFTER 1ST 12K SENT, 
;RESTORE DOS TO LO~-MEM 
sOPEN AN EXISTING FILE 
sCALCULATE MORE TO SEND 
:READ FROM DISK TO HI-MEM 
s;CLOSE DISK FILE 

;RESET STACK POINTER 
sINITIALIZE PGM POINTERS 
sCLEAR OUT DOS LO-MEM 
s;MOVE HI=-MEM TO LO-MEM 
sCALCULATE FRAMES TO SEND 
CLEAR HI-MEM 

;SEND MULTI-FRAME PACKS 


07720 ANYMOR LD 


07730 
07740 
07750 
07760 
OTTO 
07780 
07790 
07800 
07810 
07820 
07830 
07840 
07850 
07860 
07870 
07880 
07890 
07900 
07910 
07920 
07930 
07940 
OF 95:0 
07960 


LD 
ADD 
LD 
LD 
cP 
JP 
LD 
CALL 
LD 
LD 
LD 
LD 
CALL 
RET 


MUL4 LD 


i 
CY 
td 


LD 
LD 
LD 
CALL 
LD 
CALL 
RET 


A, (SECTOR) 
A,B 
(SECTOR) ,A 
A, (SEGNUM) 
1 


Z,MULA 
HL, 12032 
MUL3 
DE , FCB 

A, (SECTOR) 


DE,FCB 

A, (SECTOR) 
B,0 

C,A 

4442H 

A, (NUMSEC) 
MULO 


;SECTOR REMAINING 

3;MAX SECTORS FOR MEM 
sADD 'EM UP 

:AND SAVE IN SECTOR 
;NUMBER OF SEGMENTS 
sLAST ONE ? 

sTHEN CALCULATE LENGTH 
;MAX BYTES PER SEGMENT 
SET LBYTES LENGTH 

:;FILE CTRL BLOCK ADDRESS 
sNUMBER OF DISK SECTORS 
2256 BYTES PER RECORD 

f S1JAP SECTORS INTO ‘C’ 
:POSITION TO DISK SECTOR 
sRETURN WHENCE U CAME +1 
sONLY LAST FILE SEGMENT 
;LAST FILE SECTOR READ 
3256 BYTES PER RECORD 

3 SWAP SECTORS INTO 'C'! 
POSITION TO DISK SECTOR 
sNUMBER SECTORS REMAIIIING 
:CALCULATE BYTES TO READ 
;RETURN WHENCE U CAME +1 


END OF DISK I/O FOR AUTO MODE 


- Figure 2 


HELP Message Transmitted in Auto Mode 


MJTHIS IS W4UCH CHAUTAUQUA LAKE, NY IN AUTOMATIC DISK I/O MODEMJ 
THERE ARE FOUR FUNDAMENTAL INSTRUCTIONS THAT THIS MODE WILLMJ 
AUTOMATICALLY RECOGNIZE AFTER YOU ARE CONNECTED. THEY ARE: MJ 


1; A SINGLE. INFO: PACKET “CONSISTING OF HELP TO CALL THIS MJ 
PRESENT SUBROUTINE. MJ 
2. A SINGLE INFO PACKET CONSISTING OF LIST TO CALL THE DISK MJ 
DIRECTORY SUBROUTINE. MJ 


3. A SINGLE INFO PACKET CONSISTING OF SEND # SPACE = NAME OF MJ 
DISK PROGRAM, AND CARRIAGE RETURN TO READ THE DISK PROGRAM. MJ 
4. A SINGLE INFO PACKET CONSISTING OF SAVE # SPACE = NAME OF MJ 
DISK PROGRAM, AND CARRIAGE RETURN TO WRITE DISK PROGRAM. MJ 
THE PROGRAM WILL THEN OPEN A DISK FILE AND RESPOND WITH THEMJ 
MESSAGE, ‘SEND FILE.’ GO AHEAD AND SEND THE FILE. IF THE MJ 
FILE IS LONGER THAN 10K OR SO BYTES IN LENGTH, THE PROGRAM MJ 
WILL SEND A 'WAIT' RNR WHILE IT SAVES THE DATA ON DISK, ANDMJ 
WHEN SAVED, WILL SEND AN AUTOMATIC 'CLEAR WAIT' RR WHEN MJ 
READY FOR YOU TO RESUME SENDING THE FILE. THE MODEL 1 TRS80MJ 
DISK CAPACITY IS ABOUT 85K BYTES AND THE MODEL 3TRS80 DISKMJ 


CAPACITY IS ABOUT 170K BYTES. MJ 
MJ 
SINGLE FRAME PACKETS MAY BE UP TO 2000 BYTES IN LENGTH AND MJ 
7 FRAME PACKETS MAY HAVE INFO FIELDS OF UP TO 256BYTES. MJ 
JUST HOLD TOTAL PACKET LENGTH TO 2000BYTES OR LESS. MJ 
MJ 


WHEN YOU HAVE FINISHED SENDING THE DATA YOU WISH SAVED ON MJ 
DISK, SEND A DISCONNECT. THIS TELLS THE PROGRAM TO FINISH MJ 
SAVING YOUR DATA ON DISK AND 'CLOSE' THE FILE. WHEN THIS ISMJ 
DONE, THE PROGRAM WILL SEND AN AUTOMATIC CONNECT REQUEST MJ 
AND UPON RECEIVING THE CONNECT REQUEST ACKNOWLEDGE WILL MJ 
TELL YOU THAT THE DATA WAS SAVED. SHOULD YOU WISH TO CHECK MJ 
IT, GO AHEAD AND DO SO WITH THE SEND = SPACE # FILE NAME # MJ 


COMMAND . MJ 

MJ 

SUGGEST YOU USE THE FOLLOWING CONVENTION FOR FILE NAMES: MJ 
A. FILE NAMES MAY BE UP TO 8 UPPERCASE ALPHANUMERIC CHARACTERSMJ 
AND 'MUST' BEGIN WITH AN ALPHABETIC CHARACTER. MJ 

B. OBJECT CODE FILES SHOULD END WITH A NUMERAL 1 OR /CMD. MJ 
C. SOURCE CODE FILES SHOULD END WITH A NUMERAL 2, MJ 
D. BASIC PROGRAM FILES SHOULD END WITH A NUMERAL 4. MJ 
E. PLAIN VANILLA ASCII FILES/MESSAGES SHOULD BE ALL CAPITALS. MJ 
F. ELECTRIC PENCIL FILES SHOULD END WITH /PCL. MJ 
MJ 

THERE ARE 'NO' PROTECTED FILES ON THE DISKFILE DISK. THIS IS MJ 
INTENTIONAL. YOU MAY 'READ' ANY EXISTING FILE ON THE DISK. MJ 
WHEN ATTEMPTING TO TO WRITE TO AN EXISTING FILE YOU WILL MJ 


RECEIVE THE MESSAGE 'FILE ALREADY EXTANT # TRY ANOTHER ONE.' MJ 
IN THIS CASE, JUST GIVE THE FILE YOU WISH SAVED ANOTHER NAME MJ 
AND TRY AGAIN. MJ 


SHOULD YOU INADVERTENTLY BUGGER-UP SENDING A GIVEN FILE, FIRSTMJ 
CLOSE THE FILE BY SENDING A DISCONNECT. THE PROGRAM WILL AUTO-MJ 
MATICALLY RECONNECT TO YOU. NOW RENAME THE FILE AND TRY AGAIN.MJ 
DO NOT FORGET THE DISCONNECT TO CLOSE THE FILE. IF SO, IT MAY MJ 
BUGGER-UP THE PROGRAM FOR YOUR FELLOW AMATEURS WHO MAY WISH TOMI 
USE THE AUTO MODE LATER. MJ 

MJ 
REMINDER: CAPITAL LETTERS ARE REQUIRED FOR ALL COMMANDS AND MJ 
FILE NAMES AS SOME USERS MAY NOT HAVE THE LOWERCASE CAPABILITYMJ 
AND WOULD NOT BE ABLE TO READ THE FILE NAMES. MJ<READYOMJ 


Note: 
The capital M = ASCII Bcarriage return and the capital 


J = ASCII 10 line feed. 
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KEYBOARD INPUT MESSAGE WITH AUTOMATIC 
SWITCHING IN CONNNECTED MODE AND RETURN. 
FOR PACKET RADIO USING SOFTWARE APPROACH 


Robert M. Richardson, W4UCH 
22 North Lake Drive 


Chautauqua Lake, 


ABSTRACT: 


A number of options open to the programmer 
are discussed including manual switching, 
using interrupts, and the psuedo interrupt 
mode. The objective is to emulate as 
closely as possible the packet radio 
hardware approach (VADCG and TAPR TNCs) 
which utilize their own microprocessor, 

ROM, and RAM plus a separate host 
microcomputer. Obviously, a Single 
microcomputer using the software approach 
does not have the capability of TWO 
microcomputers (the VADCG and TAPR TNCS are 
dedicated packet microcomputers), but with 


judicious programming this problem may be 
finessed. 
INTRODUCTION: 


There are many options open to the 
programmer who is writing subroutines for 
keyboard message input. A number of 
approaches that could be used in the 
connected mode are: 


1. While keyboard inputting messages, 
ignore ALL incoming packets till the 
operator chooses to switch to receive mode. 
We will label this approach, IGNORE TILL 
READY. It is the approach used by the 
author's Volume 2 = AX.25 Protocol. 


2. Use the Model I/III TRS-80's Z-80 
microcomputer interrupt mode 1 to switch 
back and forth between keyboard input and 
transmit/receive mode data processing. This 
may be accomplished by splitting both the 
transmit AND receive ‘'bit' time delay 
countdowns between each bit processed into 
quadrants and using the quadrants for 
sequentially doing the keyboard processing; 
1.e, scanning the keyboard psuedo memory 
locations, converting the keyboard input to 
ASCII, and stashing the ASCII byte into 
memory, sequentially during each quadrant's 
idle countdown time. We will label this 
approach, INTERRUPT MODE 1. It is a rather 


fascinating challenge, but not all that 
ai fri Cults, Its major detriments are the 
amount of memory required and the 


considerable care that must be exercised to 
avoid disturbing the software digital phase 
locked loop while in receive mode or _ the 
'bit' countdown timing in transmit mode. 


3. There is yet another approach. 
While keyboard inputting a packet message 
to be transmitted in connected mode, have 
the program test the input from_ the 
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receiver (via the EXAR 221.1 AFSK 
demodulator and port zero) every 
millisecond or so and IF a valid change 
occurs, then automatically switch the 
program to receive mode where the incoming 


packet is decoded. If not for your 
station, then automatically switch back to 
keyboard input mode. If for your station 
and it was received correctly, then 
acknowledge the packet and then 
automatically switch back to keyboard input 
mode. This is the approach this paper will 
discuss with a few enhancements. We will 
call this the PSUEDO INTERRUPT approach 
Since the change in input in essence brings 
about an interrupt service subroutine. 


GENERAL: 


This software approach uses the 1024 
byte page of memory beginning at 28672 in 
memory for keyboard inputting short single 
frame packets. Long multi-frame _ packets, 
up to 12K, are input to low memory 
beginning at 17408 decimal. During the 


balance of this discussion we will presume 
you are already connected to another 
Station, As such, you would press V from 


the main menu (Figure 1) which takes’ the 
program to the edit/modify mode and 
displays a 1024 byte page of zeros 
beginning at 28672 decimal in memory. 


To activate the modify mode, press M 
to light the blinking rectangular cursor in 
the upper left hand corner of the video 
display. Most any key pressed will insert 
its ASCII value into the video display AND 
the corresponding memory location except 
for the arrow keys which move the cursor on 


the page rather quickly within the page 
boundaries, the shift zero keys which 
insert sequential decimal 128 end of 


message delimiters;, and the shift @ keys 
which display the decimal value beneath the 
cursor. 


2 is the commented source code 
for that segment of the edit/modify 
subroutine that performs the blinking 
cursor operation in modify mode, plus’ the 
test for a valid change from the receiver. 
By valid change we mean: 


Figure 


A. That the EXAR 2211 has noted a 
change from a mark to space, or. vice 
versa. 

By And that the EXAR 2211 data 


carrier detect (DCD) has not dropped. 
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Blink A starting in line 5760 stashes 
the value in video memory (IX) beneath the 
blinking cursor in the memory location 
noted by the label HOLDIT and then _ loads 
the same video location with the 
rectangular cursor character = 143 decimal. 
TEZRCV in line 5860 is then CALLed. 


Lines 5860 = 5980: 

First save registers BC, DE, HL, IX, 
and IY in the stack and then start a _ few 
millisecond countdown. Note that lines 
5880 and 5910 sample the EXAR 2211 output 
via port zero, and if any change occurs, 
then line 5930 jumps off to LOOK in line 
5990. If no change occurs during the 
countdown, line 6100 restores the saved 
registers from the stack and then returns 
whence called + l. 


Blink B starting in line 5820 simply 
replaces the stored character back onto 
video, CALLS TEZRCV, and then returns. 
Blink A and B are alternately called 
frequently enough to comfortably display 
the blink effect about 30 times a second. 


Lines 5990 — 6110: 

First test to see if the operator is 
in the connected mode = CONEKI1 set to 1. 
If not, then line 6010 jumps back to the 
TEZRCV countdown. If connected, then WATE 
is tested to see if the operator had 
previously transmitted a WAIT (RNR ) 
command, and if so, then jumps back to the 
TEZRCV countdown. The EXAR 2211 DCD is then 
tested and if dropped (no mark or_ space 
tone present), then jumps back to the 
TEZRCV countdown. If it gets this far, to 
line 6080, then SIGN10 is set = come back 
to the modify mode, the receive mode video 
display restored in 6100, and then the 
programs jumps off to receive mode to 
process the incoming packet. When done 
with the incoming packet, SIGN10 at the 
beginning of the receive mode subroutine 
sends the program off to line 6120. 


Lines 6120 = 6200: 

First zero out SIGNI1O, then save _ the 
receive mode video display in memory, 
restore the modify mode video display 
exactly the way it was before, restore all 
the modify mode registers, and lastly 
return to wherever the program was in the 
modify mode. 


OPERATION: 


When connected to another packeteer on 
an otherwise quiet non-repeater 2 meter 
frequency, this approach works perfectly. 
When on a packet digi-peater frequency it 
works very well as long as activity is low; 
i.e., not more than 2 pairs of stations on 
frequency who are NOT sending long files 
back and forth. 


IF on a busy packet digi-peater 
frequency, one has no choice but to send 
the other station a WAIT (RNR) command from 
the main menu by pressing 3, type in the 
keyboard input message, and then send it 
from the main menu by pressing V. Your info 
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packet clears your previous WAIT (RNR) 
command at the other end of the circuit. 


Another approach we tried was having 
the program send an automatic WAIT (RNR) 
command whenever you entered the modify 
mode when connected. This of course worked 
quite well, but seemed a_ rather needless 
transmission on a quiet channel, so was 
removed and left for the operator to 


perform manually when desired. Press 3 
from the main menu. 
CONCLUSION: 

This simple subroutine hopefully 
removes the last objection to our software 


approach by dyed in the wool hardcore 
hardware approach packeteers who get their 
jollies by pointing out subliminal 
differences between the 2 approaches. It is 
fully implemented in the author's 'Advanced 
Vancouver Protocol = Software Approach* 
program. 


It may easily be implemented in the 
author's "AX.25 Protocol - Software 
Approach' program if desired. During BETA 
testing of the Volume 2 = AX.25 Software 
Approach program, about 1/2 of the BETA 
testers wanted this function, while the 
other 1/2 saw no need for it as the program 
allows the operator to switch to receive 
mode manually if desired. Since the vote 
was a draw, we chose to omit it from Vol. 2 
=m AX.25. 


If you would like a disk for the 
"Advanced Vancouver Protocol = Software 
Approach' source & object programs, 
uncommented, with no instructions 
whatsoever, you are on your own, then send 
$29 for the disk (specify Model I or Model 


ELE, TRS=60)- "uo: 


Richcraft Engineering Ltd. 
#1 Wahmeda Industrial Park 
Chautauqua, New York 14722 


Alternatively, call Richcraft at (716) 
753-2654 on weekdays during business hours 
for COD shipment in the U.S. 


This program includes automatic disk 
file access in the AUTO mode by the station 
connected to your station, as mentioned 
elsewhere in these conference proceedings. 
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FIGURE 1 
VOLUME 3 MAIN MENU 


ENTER OPTION DESIRED ? a 


CHANGE ADDRESSEE CALL =A VE3NEC CONNECT REQUEST CQ = B 
NOW CONNECTED TOGGLE = iC VE3NEC DISCONNECT REQUEST = D 
SEND PACKETS FROM LO-MEM = E VE3NEC CONNECT ACKNOWLEDGE = F 
INPUT' FRAMES/PACKET LO=MEM = G THIS IS VANCOUVER FROTOCOL = H 
BACKOFF DELAY TOGGLE ON hub AUTO CONNECT TOGGLE ON = J 
NOW IN UPPER CASE MODIFY = K W2EUP # GIL BOELKE MESSAGE = L 
DISPLAY/EDIT MEMORY PAGE = ft SET INFO FIELD LOMiM PACKS = N 
NOW FORMAT VIDEO TOGGLE = 10 QUICK BROWN FOX MESSAGE = Pp 
TRANSMIT EXTERNALLY ONLY = Q SET OPENING FLAG LENGTH =R 
TRANSMIT TO HI=MEM ONLY = § INPUT/XMIT NORMAL INFO = V & T 
CLEAR NON-PGM MEM 17K=-62K = U INPUT/XMIT ALL STATION = V & W 
ABORT LOW-MEM PAK SEQUENCE = X SET RE-TRY IN CONNECT MODE = yY 
SHIFT MENU an MOVE HI-MEM TO LOW=-MEM = 
SEND WAIT REQUEST (RNR) = 3 SEND CLEAR WAIT (RR) ae | 


not shown: 
HI TO LO-MEM INSERT CR/LF <--= 


not shown: 
MOVE LOW TO HIGH MEMORY -o=> 


VOLUME 3 SHIFT MENU 


SHIFT MENU ? 


XMIT 40960 UP CONTINUOUSLY = 
LOAD HI-MEM ASCII UUUUUUU 
EDIT/MODIFY INSTRUCTIONS 
LOG ON VE3MHZ REPFSTER 
SEND MORSE I.D. 

CAUTION ** RESTORE DOS ** 
DISPLAY RECV PACKS €@ 53248 
DISPLAY CALL/ADDRESS LIST 
SAVE HI-MEM ON DISK 
TRANSMIT BAUD RATE SELECT 
CLEAR HI#HMEMORY 53248 + 


BOOT DOS READY 
LOAD HI-MEM LOGIC 1111111 
CHANGE RECEIVE DPLL BASE # 
LOG OFF VE3MHZ REPEATER 
SEND SEQUENTIAL ACKS 
DISPLAY LOW MEMORY @ 17408 
RESTORE PROGRAM POINTERS 
MOVE PROGRAM TO LOW MEMORY 
LOAD DISK FILE TO HI-MEM 
SEND DISK :1 DIRECTORY 
RECEIVE VANCOUVER PROTOCOL 
RECEIVE AX. 25NOT CONNECT SEND MORSE FROM KEYBOARD 
NORMAL DISPLAY + NOT DPLL DISPLAY DPLL LAST QUADRANT 
NOTE: SPACE BAR IN RECEIVE MODE = RESEND LAST PACK 


oun ! 
NedHwmUaeQurtow 


KSCNOOZAHOHHAOQ SP 


ronlae nog 


05720 3 
05730 


FIGURE 2 


05740 ; PSUEDO INTERRUPT AUTOMATIC SWITCH TO RECEIVE SUBROUTINE 


05750 


05760 BLINKA LD 


05770 
05780 
05790 
05800 
05810 
05820 BLINKB 
05830 
05840 
05850 


05860 TEZRCV 


05870 
05880 TZl 
05890 
05900 
05910 
05920 
05930 
05940 
05950 
05960 
05970 
05980 
05990 LOOK 
06000 
06010 
06020 
06030 
06040 
06050 
06060 
06070 
06080 
06090 
06100 
06110 
06120 RESMOD 
06130 
06140 
06150 
06160 
06170 
06180 
06190 
06200 


Cb 2 10-3 NOTES 


LD 


LD 
LDIR 
CALL 
RET 


A,( IX) 
(HOLDIT), A 
A, 143 
(IX),A 
TEZRCV 


A, (HOLDIT) 
(IX),A 
TEZRCV 


SAVE 
BC, 100 
A,(0) 
D,A 
BC 
A,(0) 
D 


NZ, LOOK 
A,B 


C 
NZ,T2Z1 
RSTOR 


A,(CONEK1) 
1 


NZ, TEZRCV+3 
A, (WATE) 

1 
Z,TEZRCV+3 
A,{0) 

0,A 
Z,TEZRCV+3 
A,l 
(SIGN10),A 
RESRCV 
BEFORI 

A 
(SIGN10),A 
SAVRCV 

HL, 28672 
DE, 15360 
BC,1024 


RSTOR 


;VIDEO MEM BYTE VALUE 
;SAVE IT IN HOLDIT 
;RECTANGULAR CURSOR 
;DISPLAY IT ON VIDEO 
3TEST INPUT CHANGE 
sRETURN WHENCE U CAME +] 
;PREVIOUS VIDEO CHARACTER 
;DISPLAY IT ON VIDEO 

3 TEST INPUT CHANGE 
;RETURN WHENCE U CAME +] 
;SAVE IY,1X,HL,DE,BC 
;COUNTDOWN VALUE 

;TEST PORT ZERO 

;STASH IT IN 'D! REGISTER 
;DECREMENT COUNTDOWN 
;TEST PORT ZERO AGAIN 
+ANY CHANGE ? 

;IF SO, TEST DCD 

;TEST COUNTDOWN 

3FOR ZERO 

;IF NOT, CONTINUE COUNT 
sRESTORE LY,1X,HL,DE,BC 
s;RETURN WHENCE U CAME +1 
;CONNECTED POINTER 

31 = CONNECTED 

;IF NOT CONNECTED, IGNORE 
s;WALT RNR POINTER 

31 = WAIT PREVIOUSLY SENT 
;IF SO, THEN IGNORE 

;TEST ITNCOMING VIA PORT 
;DATA CARRIER DETECT ? 
;IF NOT, THEN IGNORE 
;ELSE SET RETURN TO 
;MODIFY MODE POINTER 
;RESTORE RECEIVE VIDEO 
*PROCESS INCOMING PACKET 
;RESTORE MODIFY MODE 
;ZERO OUT MODIFY POINTER 
;SAVE RECEIVE VIDEO 

; BEGIN MODIFY MEMORY 

3; BEGIN VIDEO MEMORY 

;FULL PAGE TO DISPLAY 

; MOVE THEM TO VIDEO 
;RESTORE MODIFY REGISTERS 
;RETURN WHENCE U CAME +1 


06220 ;(WATE) IS RESET TO ZERO WHEN PACKET IS TRANSMITTED. 


ADDING. MULTIPGE. REPEATER CAPABILITY TO PACKET 


RADIO USING THE SOFTWARE APPROACH AX.25 VOL.2 


Robert M. Richardson, W4UCH 
22North Lake Drive 
Chautauqua Lake, N.Y. 34722 


ABSTRACT: 


A brief assembly language subroutine 
to add multiple repeater Gault letter 
decoding within the address field of a 
received AX.25 frame is described. If the 
operator's call and SSID are included in 
the multiple repeater segment of the 
address field of the received frame, the 
SSID has been repeated bit is set for each 
frame, each frame re-CRC'ed, and the entire 
packet then re-transmitted (forwarded) 
automatically by the program. Also, a 
short subroutine to allow the operator to 
input multiple repeaters' call letters into 
the address field of a packet to be 
transmitted is mentioned. 


INTRODUCTION: 
Since implementation of the 
level/layer 3 of the AX.25 packet protocol 


is taking somewhat longer than expected, a 
number of enterprising and hardy souls have 
promulgated the interim concept of adding 
multiple repeater call letters to the AX.25 
address field. Theoretically, if all the 
stations' whose calls are in the repeater 
segment of each frame's address field are 
"'on-the-air' at the same time, have antenna 
systems capable of receiving one station in 
the repeater segment of the address field 
AND transmitting to another station in the 
repeater segment of the address field, then 
this interim concept may work. 


We are not suggesting that this 
concept is theoretically unsound, but wish 
to point out the difficulties of making it 
work reliably and effectively within the 
real life amateur radio community. There 
is no question that in the laboratory it 
will work perfectly every time. There is 
no question that within the same 
metropolitan area it will work perfectly 
some of the time, Nevertheless, it is a 


fun and gqames option, so we doff our 
collective hats to those intrepid 
packeteers who created this fascinating 


feature. So as not to be the weird kid on 
the block who said "the king has no clothes 
on at all," we too have implemented this 
interesting option. 


In our software approach program we 
have allocated 2048 bytes normal and 4096 
bytes maximum, of memory for unprocessed, 
converted, received 8 bit parallel bytes 
per packet. This memory allocation allows 
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the storage and automatic forwarding of 7 
frame packets with maximum info field 
length (256 bytes) with up to forty four 
(44) repeater calls with SSIDs, also 
included in the extended address field of 
each frame. 


Using the software appproach it is 
just as easy to check the repeater segment 
of the address field of each received frame 
for the operator's call letters for upto 
44 repeaters as it is for 1 repeater, so 
Since the name of the game is multiple 
repeaters, let's do it. 


MODIFYING AX. 25 SOFTWARE APPROACH PROGRAM 
FOR FORWARDING WITH MULTIPLE REPEATERS: 


Is illustrated in Figure 1's source 
code. Line numbers are for volume 2 of 
"Packet Radio Using The Software Approach = 
AX.25 Protocol.' The commented source code 
is largely self explanatory. The only 
lines changed or added are: 12460 & 12470, 
12505 <= 12507, 12750, and 13101 = 13124. 
The program logic and flow follows. 


TEZFOR (test forward) in line 12400 is 
entered after the packet had been received 
and decoded in real-time, and each frame 
passed the CRC test. 


Lines 12400 - 12450: 

Determine the location of the frame's 
control byte (end of address field + 1) and 
store it in (RCTL). 


Lines 12460 - 12470: 

Modify the CAL (call letters 
comparison) subroutine beginning in line 
13040 so that line 13070's JP,NZ is to 
TEZNUM (test number of repeater calls in 
address field), 


Lines 12480 = 12506: 

Add 14 decimal to the frame's 
beginning address in memory, which is the 
beginning of the repeater calls, if any, 
and save it in BGNRPT. CALRPT (calculate 
number of repeaters) in line 13311 is then 
called. 


Lines 13111 —- 13122: 

Simply subtract the beginning repeater 
memory location address from the frame's 
control byte address location and if zero 

(no repeater calls in frame), go on to 
TESADR (test address) to see if the packet 
is addressed to vou. If there are 1 or 


more repeater calls in the address field, 
then the amount of memory used by the 
repeater call(s) is divided by 7 (call 
letters + SSID) and the number of repeater 
calls stashed in NUMRPT before returning to 
line 12507. 


Lines 12507 = 12520: 

Load HL with the first repeater's call 
letter first byte memory location, load DE 
with your call letter first byte memory 
location, and then call CAL in line 13040. 


Lines 13040 = 13110: 

Scan through the frame's extended 
address field searching for a match between 
your call letters and the call letters in 
the repeater segment of the frame's address 
field. If no match is found, then line 
13115 jumps off to TESADR to see if the 
frame was addressed to vou and if so, then 
process it. If a match-is found, then line 
13101 returns to line 12530. 


Lines 12530 -12550: 

First test the repeater's SSID against 
yours. The program assumes that your SSID 
byte's bit one is zero (if not, change it 
accordingly in line 12530). If not the 
same, line 12540 jumps off to TEZADR. Le 
the same, then RECRC is called to set the 
"has been repeated SSIN bit" and re-CRC the 
frame. 


Lines 12560 ~ 12630: 
Test the P/F bit of the 
control byte and if not set = more 


frame's 
frames 


in this packet, jump off to process the 
next frame in line 12710. If the P/F bit 
is set = last frame of this packet, lines 


12600 = 12610 set alternate DE with LENG! 
(total length of packet + 1) and then jump 
off to REXIT to re-transmit (forward) the 


packet. 


All this processing only requires a 
few milliseconds and is totally transparent 
to the operator except for the-<FORWARDING> 
message which is displayed on the receive 
mode video display. 


MODIFYING AX. 25 SOFTWARE APRROACH 
TO TRANSMIT MULTI-REPEATER CALLS: 


Is quite simple if only single frame 
packets are used. It seems to us that when 
using the multi-repeater function it would 
be wise to limit the packet to the single 
frame variety to keep the BERP (bit error 
rate probability) as low as_ possible. 
Further, 2 repeaters in the address field 
seems adequate for most all practical 
purposes. 


If you wish to add the multi-frame 
packet capability when using multiple 
repeaters, the software approach gives you 
total freedom to do so. The only 
limitation in our software approach is the 
memory set aside for assembled packets 
ready to be transmitted = 2048 bytes. 
Therefore, the program without too much 
modification can accomodate maximum length 
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info fields (256 bytes) with multiple 


repeaters: 


7 frames per packet 2 repeaters 
6 frames per packet = 8 repeaters 
5 frames per packet = 18 repeaters 
4 frames per packet = 35 repeaters 


If you wish to add the multi-frame AND 
multi-repeater transmit capability to our 


software approach, by all means do so. and 
we wish you well. 


CONCLUSION: 


Having more than one repeater in the 


address field of an AX.25 frame is 
certainly a temporary and possibly useful 
expedient until level/layer 3 is 
implemented. 


IF you would like a 35 track double 
sided disk for the Model I or single sided 
disk for the Model III TRS-80 with the 
multi-repeater capability in receive mode 
and up to two (2) repeaters input in 
transmit mode, then send $29 in US funds 
alo: 


Richcraft Engineering Ltd. 
#1Wahmeda Industrial Park 
Chautauqua, New York 14722 


A short single sheet of operating 
instructions is sent with the AX.25 disk 
outlining ONLY those changes to the 
operating instructions in Volume 2 of the 
software approach. Volume 2 is required for 
the balance of instructions to operate the 
program. The disk includes the PACK/CMD 
program, ASCII/CMD and MODIF1 object code 
programs, and ASCII2 and MODIF2 uncommented 
source code programs. 


These modified programs also include 
the automatic switcning from keyboard input 
message to receive mode function when 
connected, that is mentioned in another 
paper in these proceedings. The programs 
are very difficult to follow as it was 
necessary to move the real-time receive 
mode decoding subroutine from ASCII2 to the 
end of MODIF2 to allow the program to be 
assembled with a standard 2 pass editor & 
assembler in 48K of memory. Expert 
assembly languace programmers should have 


little difficulty following these changes, 
so be forewarned as we do not plan to 
re-write volume 2 LOE these modest 
improvements. 


IF you are the original purchaser of 
an earlier version of the Richcraft Ax.25 
disk program and wish it updated, return 
the original disk and $10 to have it 
updated and returned to you postpaid. 
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12400 TEZFOR LD 


12410 
12420 
12430 
12440 
12450 
12460 
12470 
12480 
12490 
12500 
12505 
12506 
12507 
12510 
12520 
12530 
12540 
12550 
12560 
12570 
12580 
12590 
12600 
12610 
12620 
12630 
12640 

12650 
12660 
12670 
12680 
12690 
12700 
12710 
12720 

12730 
12740 

12750 
12760 
12770 
12780 
12790 
12800 
12810 
12820 
12830 
12840 
12850 
12860 

12870 
12880 
12890 
12900 
12910 
12920 
12930 


ADDIT 


FRMNUM 


TESADR 


TES2 


LD 
INC 
BIT 
JP 


#- FIGURE 1 = 


HL, (BGINIT) 
A, (HL) 

HL 

0,A 
Z2,TEZFOR+3 
(RCTL) , HL 
HL, TESADR=1 
(CAL+6) , HL 
HL, (BGINIT) 
DE, 14 

HV. ,DE 
(BGNRPT) ,HL 
CALRPT 

HL, (BGNRPT) 
DE,FM 

CAL 

1, (HL) 
NZ,TEZADR 
RECRC 

HL, (RCTL) 
4, (HL) 
Z,ADDIT 


DE, (LENG1) 
DE 


REXIT 
A, (FRMNUM) 
A 


(FRMNUM) ,A 


ML, (LENG1) 
HL 


CONT 

0 

AF 
HL,MODE2-1 
(CAL+6) , HL 
HL, (BGINIT) 
DE,FM 

CAL 

A, (RPT) 

1 


Z,TES3 
DE,7 

HL, DE 

0, (HL) 
Z,MODE2 
A, (SIGN3) 
1 


Z,TESCTL 
HL, (BGINIT) 
DE, 7 

HL,DE 

DE, TO 

CAL 


:BEGIN FRAME IN MEMORY 
;LOOK FOR THE FRAME'S 
:CONTROL BYTE MEM ADDRESS 
sAFTER THE 

;LAST SSID EYTE 

;AND SAVE IT IN RCTL 
:CHANGE JP NZ ADDRESS 
:IN CALL LETTERS TEST 
BEGIN FRAME MEM LOCATION 
;UR CALL+HIS CALL+SSID'S 
sREPEATER ADDRESS IF ANY 
REPEATER BEGIN LOCATION 
sCACULATE NO, REPEATERS 
:REPEATER BEGIN LOCATION 
YOUR CALL LETTERS BEGIN 
:COMPARE WITH REPEATER 
sTEST SSID FOR YOU ? 

;IF NOT, IGNORE IT 

:;SET RPTR BIT+ RE=DO CRC 
sCONTROL BYTE LOCATION 
;P/F BIT SET = LAS? ONE 
IF NOT, DO NEXT FRAME 
:SINCE LAST ONE THEN 
*SET ALTERNATE DE TO THE 
;TOTAL PACKET 

;LENGTH + 1 FOR SEND7 
sAND RE-TRANSMIT IT 
;FRAMES PER PACK COUNTER 
PLUS ONE 

;ANND SAVE IT 

;SET ALTERNATE HI 

sFOR TOTAL PACK 

3+ 1 FOR SEND7 

sRESTORE REG. REGISTERS 
3GO PROCESS NEXT FRAME 
:FRAMES/PACK COUNTER 
sADJUST STACK FOR CALL 
:RESET JP,NZ ADDRESS 

; IN CALL COMPARISON 
BEGIN FRAME MEM LOCATION 
; YOUR CALL LETTERS BEGIN 
sCOMPARE WITH YOUR CALL 
;VIA REPEATER POINTER 

71 = ON 2 = OFF 

:IF SO, TEST RPTR CALL 
:NOT VIA REPEATER, 

3;SO TEST OTHER STATION'S 
:SSID BIT ZERO TO ENSURE 
:IT IS DIRECT OR IGNORE. 
;AUTO MODE POINTER 

31 = ON 0 = OFF 

;IF AUTO, TEST CONTROL 
;ELSE TEST HIS 

sCALL LETTERS 

sAGAINST THE 

sCALL TO WHICH 

;YOU ARE CONNECTED. 


12940 
12950 TES3 
12960 
12970 
12980 
12990 
13000 
13010 
13020 
13030 
13040 CAL 
13050 
13060 
13070 
13080 
13090 
13100 
13101 
13102 


13103 TEZNUM 


13104 

13105 

13106 

13107 

13108 

13109 

13110 

13111 CALRPT 
13112 

13113 

13114 

13115 

13116 

13117 

13118 

13119 

13120 

13121 

13122 

13123 BGNRPT 
13124 NUMRPT 
13130 REXIT 
13140 

13150 

13160 

13170 

13180 

13190 

13200 

13210 

13220 

13230 

13240 

13250 

13260 

13270 

13280 

13290 

13300 
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TESCTL 
DE 

DE 

DE, 8 

HL ,DE 
DE 

CAL 

7, (HL) 
Z,MODE2 
TES2 

BC ,6 

A, (DE) 
(HL) 
NZ,MODE2-1 
DE 

HL 

Cc 

Zz 

CAL+3 
A, (NUMRPT) 
A 


(NUMRPT) ,A 
Z,TESADR~1 
DE, FM 


CAL 
HL, (RCTL) 
DE, (BGNRPT) 


A 

HL,DE 
Z2,TESADR~1 
DE, HL 

HL,7 


A,L 
(NUMRPT) ,A 


0 


0 

LY ,37873 
SHOWLT 
DE, (FNDIT) 
HL, (REX) 
HL 

IY 

A, (FRMNUM) 


0 
Z,SFRM1 
NZ, SFRM2 
A,1 
(LASONE) ,A 
A 
(ZEROMK) ,A 
(ZEROSP) ,A 
(FRMNUM) ,A 
SETIT 
FLGDLY 


:OK, SO TEST CONTROL 
;VIA REPEATER 

3;SO TEST 

: REPEATER 

sCALL 

; LETTERS 

sAND IF OK, 

:THE REPEATED SSID BIT. 
sNOT REPEATED, SO IGNORE 
:NOW TEST HIS CALL LTRS 
;RPTR/CALL COMPARISON 
;FRAME MID-MEM ADDRESS 
:UR CALL LETTERS ADDRESS 
NOT SAME ? THEN EXIT 
;NEXT MID-MEM ADDRESS 
sNEXT COMPARISON ADDRESS 
3-1 CALL LETTER COUNTER 
;ALL MATCH, SO RETURN 
:GO TEST NEXT LETTER 
;NUMBER REPEATER CALLS 
sLESS ONE 

;AND SAVE IT IN MEMORY 
:IF ZERO GO TEST ADDRESS 
;UR CALL MEMORY LOCATION 
;SKIP SSID FOR NOW 

sNEXT RPTR CALL LOCATION 
3GO TEST NEXT RPTR CALL 
:END REPEATER CALLS + 1 
:BEGIN RPTR MEM LOCATION 
sCLEAR CARRY FLAG 

:;RTCTL MINUS BEGIN RPTR 
3;IF ZERO, TEST ADDRESS 
sREPEATER BYTES TO DE 

:6 CALL LETTERS + SSID 
sDIVIDFE HL INTO DE 
:SINGLE PREC. TO INTEGER 
:NUMBER REPEATER CALLS 
;STASH THEM IN MEMORY 
7;GOTO LINE 12530 

;SAVE 2 BYTES FOR ADDRESS 
*SAVE 1 BYTE RPTR COUNT 
;DISPLAY <FORWARDING> 
MESSAGE ON VIDEO 
s;CLOSING FLAG ADDRESS 
:MID-MEM BEGIN ADDRESS 
SWAP HL 

s INTO IY 

;FRAMES/PACKET COUNTER 
?SINGLE FRAME PACKET ? 
:IF SO, SET FOR SINGLE 
ELSE SET MULTI-FRAME 
SET THE XMIT SUBROUTINE 
LAST ONE POINTER 

ZERO OUT TRANSMIT 

s;MARK COUNTER 

sAND SPACE COUNTER 

AND FRAME COUNTER TOO 
?SETUP FOR SEND7 XMIT 
:FINALLY «- GO SEND IT 


Appendix 


The following document is reprinted by permission 
of the Director, CCIR. Recommendation 4/6-3 specifies 
the protocol for AMTOR (Amateur Teleprinting Over Radio) 
and is referenced in FCC rules section 97.69. 


RECOMMENDATION 476-3 * 


DIRECT-PRINTING TELEGRAPH EQUIPMENT IN 
THE MARITIME MOBILE SERVICE 


(Question 5/8) 
(1970-1974-1978-1982) 


The CCIR, 
CONSIDERING 
a) that there is a requirement to interconnect mobile stations, or mobile stations and coast stations, equipped 


with start-stop apparatus employing the International Telegraph Alphabet No. 2, by means of radiotelegraph 
circuits; 

b) that direct-printing telegraphy communications in the maritime mobile service can be listed in the 
following categories: 

ba telegraph service between a ship and a coast station; 

bb telegraph service between a ship and an extended station (ship’s owner) via a coast station; 

b.c telex service between a ship and a subscriber of the (international) telex network; 

bd broadcast telegraph service from a coast station to one or more ships; 


be telegraph service between two ships or between one ship and a number of other ships; 


* — The Director, CCIR is requested to bring this Recommendation to the attention of the CCI’TT 
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c) that those categories are different in nature and that consequently different degrees of transmission quality 
may be required; 

d) that the categories given in b.a, b.b and b.c above may require a higher transmission quality than 
categories b.d and b.e for the reason that data could be handled through the services in the categories b.a, 6.6 and 


b.c, while the messages passed through the service of category b.d, and via the broadcast service of category b.e 
are normally plain language, allowing a lower transmission quality than that required for coded information; 


e) that the service in category b.d and the broadcast service in category b.e cannot take advantage of an ARQ 
method, as there is in principle no return path; 

fp that for these categories of service which by their nature do not allow the use of ARQ, another mode, Le. 
the forward error-correcting (FEC) mode should be used; 

g) that the period for synchronization and phasing should be as short as possible and should not exceed 
5 seconds; 

h) that most of the ship stations do not readily permit simultaneous use of the radio transmitter and radio 
receiver; 

dD) that the equipment on board ships should be neither unduly complex nor expensive; 


k) that provision is made in Appendix 38 of the Radio Regulations for direct-printing telegraph operation, 


UNANIMOUSLY RECOMMENDS 


l. that when an error-detecting and correcting system is used for direct-printing telegraphy in the maritime 
mobile service, a 7-unit ARQ system or a 7-unit forward acting, error-correcting and indicating time-diversity 
system, using the same code, should be employed; 


2 that equipment designed in accordance with § 1 should meet the characteristics laid down in Annex I. 
ANNEX I 

1, General (Mode A, ARQ and Mode B, FEC) 

1.1 The system is a single-channel synchronous system using the 7-unit error-detecting code as listed in § 2 of 

this Annex. 


1.2 The modulation rate on the radio link is 100 bauds. The equipment clocks controlling the modulation rate 
should have an accuracy of better than 30 parts in 10°. 


Note. — Some existing equipments may not conform to this requirement. 


1.3 The terminal input must be able to accept the 5-unit start-stop CCITT International Telegraph Alphabet 
No. 2 at a modulation rate of 50 bauds. 


1.4 The frequency shift on the radio link is 170 Hz. When frequency shift is effected by applying audio signals 
to the input of a transmitter, the centre frequency of the audio spectrum offered to the transmitter should be 


1700 Hz. 


Note. — A number of equipments are presently in service, using a centre frequency of 1500 Hz. These may 
require special measures to achieve compatibility. 


fee) The radio frequency tolerance of the transmitter and the receiver should be in accordance with 
Appendix 38 of the Radio Regulations. It is desirable that the receiver employs the minimum practicable 


bandwidth (see also Report 585). 
Note. — The receiver bandwidth should preferably be between 270 and 340 Hz. 
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2. Table of conversion 


2.1 Traffic information signals 
TABLE I 


International 


Combi- Emitted 


ae Gage Alphabet No. 2 
0. Code 


Letter- Telegraph anit 
signal (') 


BBBYYYB 

YBYYBBB 

BYBBBYY 

BBYYBYB 

YBBYBYB 

BBYBBYY 

BYBYBBY 

BYYBYBB 

BYBBYYB 

Audible signal BBBYBYY 
| YBBBBYY 

) BYBYYBB 
BYYBBBY 
BYYBBYB 
BYYYBBB 
BYBBYBY 
YBBBYBY 
BYBYBYB 
BBYBYYB 
YYBYBBB 
YBBBYYB 
YYBBBBY 
BBBYYBY 
YBYBBBY 
BBYBYBY 
BBYYYBB 
(Carriage return) YYYBBBB 
(Line feed) YYBBYBB 
(Letter shift) YBYBBYB 
(Figure shift) YBBYBBY 
YYBBBYB 

YBYBYBB 


WH 0 ~ID tab W WO — 


2+ tN <K s< CHUMRDoVSE] SOKO ToODMMOTp 
+ oOr~- Hj} Ame -e-Of 


Space 
Unperforated tape 


(') B represents the higher emitted frequency and Y the lower. 

(7) At present unassigned (see CCITT Rec. El C8). Reception of these signals, however, should not initiate a request 
for repetition. 

(*) The pictorial representation shown is a schematic of pfawhich may also be used when equipment allows (CCITT 


Rec. F.1). 


2.2 Service information signals 


TABLE II 


Mode A (ARQ) Emit ted signal Mode B (FEC) 


Control signal 1 (CS1) BYBYYBB 


Control signal 2 (CS2) YBYBYBB 


Control signal 3 (CS3) BYYBBYB 
Idle signal 8 BBY YBBY 


Idle signal a BBBBYYY Phasing signal | 
Signal repetition YBBYYBB Phasing signal 2 


3. Charactenstics 


3.1 Mode A (ARQ) (see Figs. 1 and 2) 


A synchronous system, transmitting blocks of three characters from an Information sending station (ISS) 
towards an information receiving station (IRS), which stations can, Controlled by the control signal 3 (see § 2.2). 
interchange their functions. 
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3.1.1. Master and slave arrangements 


3.1.1.1 The station that initiates the establishment of the circuit (the calling station) becomes the “master” 
station, and the station that has been called will be the “slave” station; 


this situation remains unchanged during the entire time in which the established circuit is 
maintained, regardless of which station, at any given time, is the Information Sending Station (ISS) or 
Information Receiving Station (IRS); 


3.1.1.2 the clock in the master station controls the entire circuit (see circuit timing diagram, Fig. 1); 


3.1.1.3 the basic timing cycle is 450 ms, and for each station consists of a transmission period followed by 
a transmission pause during which reception is effected ; 


3.1.1.4 the master station transmitting time distributor is controlled by the clock in the master station; 
3.1.1.5 the slave station receiving time distributor is controlled by the received signal; 


3.1.1.6 the slave station transmitting time distributor is phase-locked to the slave station receiving time 
distributor; i.e. the time interval between the end of the received signal and the start of the transmitted 
signal (t- in Fig. 1) is constant; 

3.1.1.7 the master station receiving time distributor is controlled by the received signal. 


3.1.2 The Information Sending Station (ISS) 


3.1.2.1 Groups the information to be transmitted into blocks of three characters (3 x 7 signal elements), 
including, if necessary, “idle signals $B” to complete or to fill blocks when no traffic information is 
available; 

3.1.2.2 emits a “block” in 210 ms after which a transmission pause of 240 ms becomes effective, retaining 
the emitted block in memory until the appropriate control signal confirming correct reception by the 
Information Receiving Station (IRS) has been received; 


3.1.2.3 numbers successive blocks alternately “Block 1” and “Block 2” by means of a local numbering 
device. The first block should be numbered “Block 1” or “Block 2” dependent on whether the received 
control signal (see § 3.1.4.5) is a control signal 1 or a control signal 2. The numbering of successive blocks 
is interrupted at the reception of: 


— a request for repetition; or 

— a mutilated signal; or 

- acontrol signal 3 (see § 2.2); 

3.1.2.4 emits the information of Block 1 on receipt of control signal 1 (see § 2.2); 

3.1.2.5 emits the information of Block 2 on receipt of control signal 2 (see § 2.2); 

3.1.2.6 emits a block of three “signal repetitions” on receipt of a mutilated signal (see § 2.2). 


3.1.3. The Information Receiving Station (IRS) 


3.1.3.1 Numbers the received blocks of three characters alternately “Block 1” and “Block 2” by a local 
numbering device, the numbering being interrupted at the reception of: 


— a block in which one or more characters are mutilated; or 
-~ a block containing at least one “signal repetition’; (3.1.2.6) 


3.1.3.2 after the reception of each block, emits one of the control signals of 70 ms duration after which a 
transmission pause of 380 ms becomes effective; 


3.1.3.3 emits the control signal | at the reception of: 

— an unmutilated “Block 2”, or 

— a mutilated “Block 1”, or 

— Block 1” containing at least one “signal repetition’; 
3.1.3.4 emits the control signal 2 at reception of: 

— an unmutilated “Block 1’, or 

— a mutilated “Block 2”, or 

— a “Block 2” containing at least one “signal repetition”. 


3.1.4 Phasing 


3.1.4.1 When no circuit is established, both stations are in the “stand-by” position. In this stand-by 
position no ISS or IRS and no master or slave position is assigned to either of the stations; 


3.1.4.2 the station desiring to establish the circuit emits the “call” signal. This “call” signal is formed by 
two blocks of three signals; 
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3.1.4.3 the call signal contains: 

~ in the first block: “signal repetition” in the second character place and any combination of 
information signals * in the first and third character place, 

~ in the second block: “signal repetition” in the third character place preceded by any combination of 
the 32 information signals * in the first and second character place; 

3.1.4.4 on receipt of the appropriate call signal the called station changes from stand-by to the I R S 

position and emits the control signal 1 or the control signal 2; 

3.1.4.5 on receipt of two consecutive identical control signals, the calling station changes intoI S Sand 

operates in accordance with § 3.1.2.4 and 3.1.2.5. 


3.1.5 Rephasing ** 

3.1.5.1 When reception of information blocks or of control signals is continuously mutilated, the system 

reverts to the “stand-by” position after a predetermined time (a preferable predetermined time would be 

the duration of 32 cycles of 450 ms), to be decided by the user, of continuous repetition; the station that is 

master station at the time of interruption immediately initiates rephasing along the same lines as laid down 

in § 3.1.4; 

3.1.5.2 if, at the time of interruption, the slave station was in the IRS position, the control signal to be 

returned after phasing should be the same as that last sent before the interruption to avoid the loss of an 

information block upon resumption of the communication. (Some existing equipments may not conform to 

this requirement); 

3.1.5.3 however, if, at the time of interruption, the slave station was in the ISS position, it emits, after 

having received the appropriate call blocks, either: 

— the control signal 3; or 

~— the control signal 1 or 2 in conformity with § 3.1.4.4, after which control signal 3 is emitted to initiate 
changeover to the ISS position; 

3.1.5.4 if rephasing has not been accomplished within the time-out interval of § 3.1.9.1, the system reverts 

to the stand-by position and no further rephasing attempts are made. 


3.1.6 Change-over 


3.1.6.1 The Information Sending Station (ISS) 

~— Emits, to initiate a change in the direction of the traffic flow, the information signal sequence “Figure 
shift” -— “Plus” (“figure case of Z”) — “Question Mark” (“figure case of B”) *** followed, if 
necessary, by one or more “Idle Signals B” to complete a block; 

~— emits, on receipt of a control signal 3, a block containing the signals “Idle Signal B” ~ “Idle 
Signal a” — “Idle Signal B”; 

— changes subsequently to IRS after the reception of a “signal repetition”. 


3.1.6.2 The Information Receiving Station (IRS) 
— Emits the control signal 3: 

(a) when the station wishes to change over to ISS, 

(b) on receipt of a block in which the signal information sequence “Figure shift” — “Plus” — 
(figure-case of Z) ~ “Question Mark” (figure-case of B) terminates *** or upon receipt of the 
following block. In the latter case, the IRS shall ignore whether or not one or more characters in 
the last block are mutilated: 

~ changes subsequently to ISS after reception of a block containing the signal sequence “Idle signal B” 

— “Idle signal a” “Idle signal B”; 

— emits one “signal repetition” as a master station, or a block of three “signal repetitions” as a slave 
station, after being changed into ISS; 


3.1.7 Output to line 


3.1.7.1 the signal offered to the line output terminal is a 5-unit start-stop signal at a modulation rate of 
50 bauds. 


3.1.8 | Answerback 


3.1.8.1 The WRU (Who are you?) sequence, which consists of combination Nos. 30 and 4 in the 
International Telegraph Alphabet No. 2, is used to request terminal identification. 


* The composition of these signals and their assignment to individual ships require international agreement (see Recommen- 
dation 491). 
** Some coast stations do not provide rephasing (see also Recommendation 492). 
*** Tn the Telex network, the signal sequence combination No. 26 - combination No. 2, sent whilst the teleprinters are in the 


figure case condition, is used to initiate a reversal of the flow of information. The IRS is, therefore, required to keep track 
of whether the traffic information flow is in the letter-case or figure-case mode to ensure proper end-to-end operation of the 


system. 
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3.1.8.2 The Information Receiver Station (IRS), on receipt of a block containing the WRU sequence, 
which will actuate the the teleprinter answerback code generator: 
~ changes the direction of traffic flow in accordance with § 3.1.6.2; 
- transmits the signal information characters derived from the teleprinter answerback code generator; 


— after transmission of 2 blocks of “Idle signals B” (after completion of the answerback code, or in the 
absence of an answerback code), changes the direction of traffic flow in accordance with § 3.1.6.1. 


Note. « Some existing equipments may not conform to this requirement. 
3.1.9 End of communication 


3.1.9.1 When reception of information blocks or of control signals is continuously mutilated, the system 
reverts to the “stand-by” position after a predetermined time of continuous repetition, which causes the 
termination of the established circuit, (a preferable predetermined time would be the duration of 64 cycles 
of 450 ms); 

3.1.9.2 the station that wishes to terminate the established circuit transmits an “end of communication 
signal”; 

3.1.9.3 the “end of communication signal” consists of a block containing three “Idle Signal a”: 

3.1.9.4 the “end of communication signal” is transmitted by the ISS; 

3.1.9.5 if an IRS wishes to terminate the established circuit it has to change over to ISS in accordance 
with § 3.1.6.2; 

3.1.9.6 the IRS that receives an “end of communication signal” emits the appropriate control signal and 
reverts to the “stand-by” position; 

3.1.9.7 on receipt of a control signal that confirms the unmutilated reception of the “end of communica- 
tion signal’, the ISS reverts to the “stand-by” position; 


3.1.9.8 when after a predetermined number of transmissions * of the “end of communication signal” no 
control signal has been received confirming the unmutilated reception of the “end of communication 
signal”, the ISS reverts to the stand-by position and the IRS times out in accordance with § 3.1.9.1. 


Mode B, forward error correction (FEC) (see Figs. 3 and 4) 


A synchronous system, transmitting an uninterrupted stream of characters from a station sending in the 


collective B-mode (CBSS) to a number of stations receiving in the collective B-mode (CBRS), or from a station 
sending in the selective B-mode (SBSS) to one selected station receiving in the selective B-mode (SBRS). 


3.2.1. The station sending in the collective or in the selective B-mode (CBSS or SBSS) 


3.2.1 .1 Emits each character twice: the first transmission (DX) of a specific character is followed by the 
transmission of four other characters, after which the retransmission (RX) of the first character takes place, 
allowing for time-diversity reception at 280 ms time space; 

3.2.1.2 emits as a preamble to messages or to the call sign, alternately the phasing signal | (see § 2.2) and 
the phasing signal 2 (see § 2.2) whereby phasing signal | is transmitted in the RX, and phasing signal 2 in 
the DX position. At least four of these signal pairs (phasing signal | and phasing signal 2) should be 
transmitted. 


3.2.2 The station sending in the collective B-mode (CBSS) 


3.2.2.1 Emits during the breaks between two messages in the same transmission the phasing signals 1 and 
the phasing signals 2 in the RX and the DX position, respectively. 


3.2.3 The station sending in the selective B-mode (SBSS) 


3.2.3.1 Emits after the transmission of the required number of phasing signals (see § 3.2.1.2) the call sign 
of the station to be selected. This call sign is a sequence of four characters that represents the number code 
of the called station. This transmission takes place in the time diversity mode according to § 3.2.1.1; 

3.2.3.2 emits the call sign and all further signals in a 3B/4Y ratio, i.e. inverted with respect to the signals 
in Table I of § 2 in the column “emitted 7-unit signal”. Consequently, all signals, i.e. both traffic 
information signals and service information signals, following the phasing signals are transmitted in the 
3B/4Y ratio; 


3.2.3.3 emits the service information signal “Idle signal B” during the idle time between the messages 
consisting of traffic information signals. 


A preferable predetermined number would be four transmissions of the “end of communication signal’. 
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3.2.4 The station(s) receiving in the collective or in the selective B-mode (CBRS or SBRS) 


3.2.4.1 Checks both characters (DX and RX), printing an unmutilated DX or RX character, or printing an 
error symbol or space, if both are mutilated. 


3.2.5 Phasing 


3.2.5.1 When no reception takes place, the system is in the “stand-by” position as laid down in § 3.1.4.1; 


3.2.5.2 on receipt of the sequence “phasing signal |” - ‘phasing signal 2", or of the sequence “phasing 
signal 2” — “phasing signal /”, in which phasing signal 2 determines the DX and phasing signal 1 


determines the RX position, and at least one further phasing signal in the appropriate position, the system 
changes from “stand-by” to the CBRS position; 


3.2.5.3 when started as CBRS the system changes to the SBRS (selectively called receiving station) position 
on receipt of the inverted characters representing its selective call number; 


3.2.5.4 having been changed into the CBRS or into the SBRS position the system offers continuous 
stop-polarity to the line output terminal until either the signal “carriage return” or “‘line feed” is received; 


3.2.5.5 when started as SBRS, the decoder re-inverts all the following signals received to the 3Y/4B ratio, 
so that these signals are offered to the SBRS in the correct ratio, but they remain inverted for all other 


Stations; 


3.2.5.6 both the CBRS and the SBRS revert to the stand-by position if, during a predetermined time, the 
percentage of mutilated signals received has reached a predetermined value. 


3.2.6 Output to line 


3.2.6.1 The signal offered to the line output terminal is a S-unit start-stop CCITT International Telegraph 
Alphabet No. 2 signal at a modulation rate of 50 bauds. 


3.2.7. End of emission 


3.2.7.1 The station sending in the B-mode (CBSS or SBSS) that wishes to terminate the emission transmits 
the “end of emission signal”; 


3.2.7.2 the “end of emission signal” consists of three consecutive “idle signals a” (see § 2.2) transmitted in 
the DX position only, immediately after the last transmitted traffic information signal in the DX position, 
after which the station terminates its emission and reverts to the “stand-by” position; 


“end of emission signal” 


OX-posit ton 
RX-position 


revert to “stand-by” 


3.2.7.3 the CBRS or the SBRS reverts to the “stand-by” position not less than 210 ms after receipt of at 
least two consecutive “idle signals «” in the DX position. 
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*The transmission of these signals may be omitted. 
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Selective call No. 32610 transmitted as 


(see Rec. 491 § 2 ,3) 
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Basic timing cycle 


FIGURE | ~ A-Mode operation 


a) Start of communication 
b) Change of the direction of the traffic flow 
c) End of communication 

CS: Control signal 


ISS : Information sending station 
IRS : Information receiving station 
RQ: Signal repetition information signal 


t: Figure shift 
t,: (One way) propagation time 
t_: (Fixed) equipment delay 
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FIGURE 2 ~ ModeA under error recaving conditions 
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FIGURE 3 = B-mode operation 
Hecti Selectively 
1 eer eaee 1 CBSS: B-mode = Sending collectively 
2: Phasing signal 2 CBRS: B-mode ~ Receiving collectively 
<: Carriage return (CR) SBSS: B-mode = Sending selectively 
a: Line feed (LF) SBRS: B-mode = Receiving selectively 


@_ : Detected error symbol 


Overlined symbols (e.g. M) are transmitted in the 3B/4Y ratio 


3. 134 


Fourth 
ARRL Amateur Radio 
Computer Networking 
Conference 


March 30, 1985 
San Francisco 


Coordinators: 
Paul L. Rinaldo, W4RI 
Dr. Henry S. Magnuski, KA6M 


COMMUNICATIONS PROTOCOLS FOR THE NETWORK AND TRANSPORT LAYERS ' OF 


THE AMATEUR PACKET NETWORK 


3. Gordon Beattie, Jr., N2DSY 
Thomas A. Moulton, W2VY 


The Radio Amateur Telecommunications Society 
206 North Vivyen Street 
Bergenfield, NJ 07621 

201-387-8896 


ABSTRACT determined by physicai layer standards. 
There has been much discussion among Link Layer ~- level 2 

amateurs about internetworking with This layer defines the functions of two 
other areas oof the country and = globe. directly connected points in a network. 
This has led to the introduction of Link establishment, data transfer, fiow 
terms into the vocabulary of many control, error control and term ination 
amateurs, many of whom are newly are defined. 

equipped with computers ! In this paper 

we will present the [S0/CCITT Open Network Layer - level 3 

Systems concept and its impact on the This layer defines the means to 
protocols we wili be using to provide establish, maintain and terminate 
reliable data transfer in the amateur network connections through a_ series of 
network. In order to provide a basis links which compose one or more 
for contrast, we will also introduce the networks. Link multiplexing, flow 
U.S. Department of Defense protocols. control and sequencing of data are also 


defined in this layer. 
First we wiil define the basic concepts 


and terms needed to understand the Transport Layer - level 4 

protocol issues. Once this groundwork This layer provides the means to _ ensure 
is laid, we will explore the protocols reliable data transfer between end 
needed to provide a reliable data points in the network. Depending on the 
transfer capability. Conclusions will characteristics of tlhe network layer, 
be drawn based upon the experience of different error handling capabilities 
the writers and their amateur and will be required of the transport layer. 
professional associates. The transport layer must be prepared to 


supply the required reliability if it is 
unable to obtain a reasonable grade of 
TERMS service from the network layer. 


Session Layer - level 5 


osi - The session layer is responsible for 

Open Systems Interconnection Model calling upon the resources required to 
The goal of "open systems” is to allow complete a distributed communications 
dissimilar computers, networks and task via a network or networks. A 
terminals to operate together in a simple session would be a file transfer 
common network environment. There are between two stations in real-time. An 
seven layers or functions defined in the example of a more complex session would 
model. They provide the basis for be a station obtaining needed 
interoperability. Standards bodies ali information from a group of databases in 
over the world have evolved in an order to locate and properly conduct a 
unprecedented way to Jointly develop series of message transfers with a 
these standards for the dispersed group of destinations. 
telecommunications and computer 
industries. Presentation Layer = level 6 

The presentation layer is responsible 
Layer = for code and format conversion between 
A functional segment of the OSI _ model. end users. Baudot to ASCII conversion 
There are seven. would be the responsibility of this 
layer. 

Physical Layer ° level 1 
This layer addresses all physical Application Layer °* level 7 
aspects of the communications medium. This layer defines message formats’ and 
Voltage, frequency, interface lead procedures used by such applications as 
assignment and connector layout are all electronic mail, bullk file transfer and 
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remote data processing. 


Virtual Circuit <- (VC) 


A logically-linked path through a 


network or networks over which data is 
passed between end users. They usually 
are setup using call establishment 
procedures, used for the period of data 
transfer, then disolved. 


Datagramme - 


A data unit which contains all 
neccessary information for routing, 
error control, sequencing and throughput 
requirements in addition to the actual 


user data. 


Fast Select = 
An X.25 Call Request with 128 bytes of 
user data. 


CCITT: * 

International Consultive Committee for 
Telephone and Telegraph. This organiza-— 
tion coordinates standards-making 
activities in the telecommunications 
field. 

Iso - 

The International Organization for 
Standardization 

This body along with the CCITT, 
formalized the Open System concept and 
the protocols required to perform the 
functions of each layer. 

X.25 = 

A CCITT standard for packet switched 
network interfaces. Lt includes 
recommendations for the first three 


layers of the ISO model. AX.25 level 2 


was an adaptation of the Link layer of 
X.25. Level 3 of X.25 provides for a 
"virtual circuit" to be used as a_ path 


for data transfer. 
X.224 - 


A CCITT standard defining the transport 
protocol for use in OSI applications. 
TPDU + Transport Protocol Data Unit 


Internet Protocol « 


A datagramme-oriented networking 
protocol. This level i protocol was 
adopted by the U.S. Department of 
Defense (DoD) for use on its Advanced 
Research Project Agency Network 
(ARPANET) , 

TCP - 


A transport protocol developed by the 


DoD for ARPANET. 


This level 4 protocol was developed to 
provide end-to-end error recovery in a 
datagramme-based network. 

THE REAL ISSUES 

The Os1 model defines peer-level 
protocols to be used in corresponding 
communicating entities. The OSI concept 
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separates the issues before us into two 
ciistinct tasks: 


1. The selection of a network layer 
(level 3) protocol. 
The network layer protocol options 


are the ISO/CCITT x.25 level 3 and 
the U.S. DoD Internet Protocol. 


2. The selection of a transport layer 
(level 4) protocol. 
The transport layer options are the 
ISO/CCITT X.224 and the U.S. DoD 
Transmission Control Protocol ‘TCP). 


Diagramme 1 shows where these protocols 
fit in the OSI scheme of things. 


THE NETWORK LAYER 
em-—— 


—, arnr-r-n 


ae ow 


The first area of concern is the 
dissimilar way these protocols pass data 


through a network. The X.25 level 3 
protocol has three phases: call set-up, 
data transfer and call release. A 
station sets up a path over which data 
is passed, then transfers the data. The 
protocol exchange for a virtual circuit 
(VC) based data transfer would be as 
shown below. 

The DoD Internet Protocol uses 
datagrammes to provide the needed 


control to route the packets through the 


network. There is no "@connection" 
between network the sender and receiver 
of the the network layer data. Upper 
layers provide this, leaving the network 
layer with the tasks of routing. As we 
will see, this puts a large burden on 
the end-users of the network and limits 


throughput by increasing overhead. 


The basic issues in deciding between the 
ISO/CCITT xX.25 level 3 and U.S. DoD 
Internet Protocol are: 


Protocol Efficiency; 
Reliability; 

Ease of Implementation; 
Interoperability with 
Networks: 

5. International Acceptance. 


PWNHe 


Non-Amateur 


1. Protocol Efficiency 

The set-up or call establishment 
procedure allows all stations involved 
in the call to negotiate the parameters 
needed to transfer the data over the VC. 


This is accomplished through the Call 
Request and Call Accept exchange. It 
also identifies the end points to all 
stations involved so that each packet 
exchanged with user data need only 
contain a logical identifier. Each 
station supporting the call must 
maintain a table entry reflecting the 
path through the station itself and the 


current state of that call. 


During call establishment, parameters 
are exchanged which govern the data flow 
of that call. Some of these parameters 
are outlined below: 


Packet Window Size - 

Lets each station know how many 
unacknowledged packets may be 
outstanding before an acknowledgement is 
required. 


Packet Size - 

Determines the amount of data in each 
packet. It must be set to a power of 
two <e.g. 128/256/512/1024 etc.), 


Throughput Class - 
An indication of the required 
service needed to support the call. 


level 


Extended Address - 
A way to indicate the actual stations in 
networks 


the source and destination 

using the locally defined address (e.g. 
W2VY-S). 

The exchange in diagramme 2 shows” end- 
to-end Significance to the packet 
sequence numbers, but at the option of 
the network it may be locally 
acknowledged. The Call Request'= and 
Accept packets may also contain up to 


128 bytes of user data. 


Datagrammes contain source and 
destination addresses, service type, and 
time-to-live information in each packet. 


This information is used by the packet 
switches to route, and if necessary 
discard, the packet. Most packet 
switches in commercial networks require 
8-15 times the CPU resources to handle 
routing functions than they do _ for 
simple data transfer across an 


estblished path. 


data 
paths 
out of 
increase 


The datagramme approach allows for 
units to be sent over random 
causing them to often arrive 
sequence. This is done to 
reliability in the network, but such a 
measure is unneccessary and forces’ the 
transport layer to handle sequence 
management, complicating the functions 
of the end user terminals. 


The ammount of overhead in the Internet 
Header is extensive when compared to 
that of the X.25 level 3 header. There 


are two cases which require examination: 


Ly Datagramme vs. Fast Select Packet 
23 Datagramme vs. Data Packet. 
An X.25 Fast Select call is a normal 


X.25 call with up to 128 bytes of user 
data included. It may be acknowledged 
with either an accept or a clear with up 
to 128 bytes of user data. In either 
case it mirrors the function of the 
datagramme protocol by creating 
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independent data units while at the same 


time allowing for VC-based exchanges 
using the same protocol sequence and 
network. 


An IP datagramme will usually contain 20 
bytes of overhead in each packet. 


The X.25 Fast Select Call Packet will 
typically contain twenty-four (24) bytes 
of overhead. 


The X.25 Data Packet will contain three 
(3) bytes of overhead. 
The format of a typical Fast Select 


packet would be as shown below. 


X.25 


Call Request 


a el 


ste he te ete alte cle ats ci os ae i om ain a ie aim Ok eee i ame em om owt am ah ote ame nt af ot nf aie ot om ot ee 


te meme ee ea te i eee ew ie i i as oe 


—- oe ee oe ee eee we te asia ee 


te te tee ete eee me ee ate em ts ee te as ee ae et oo 


te fe ie ote am ote ee me om ee me oe eee eee ae we om am me am mt om ae em oe am ow 


ete as i te ee ee tee ee te me a le ae ts ae ae i i oh 


i User Data 


l up to 128 bytes 


a ale ote ahs mee ty eat tml ee me nee mom ome te ale eis oe at om ie a om ie im ah on on 


Data packets exchanged after the call is 
established use the format found in 


diagramme 4. 


The format of a typical datagramme 
packet would be as shown below. 


Internet Protocol Datagramme 


ee ew mh a a a am ae am oe wm om a a th ek om tk 


| Version | IHL 

ee Type of Service 1 
ae Total Length” 1 
i Total Length (cont.) 1 


a me ee ee om om ah am om am em oe am em om oe we wm ote ate nie eh of om a om ah ab om om am ow oe 


Offset (cont.) I 


l Protocol l 
a es es ees “aes es l------------------ 


| Header Checksum | 


ee te om a em em oe ee am Ge amb om ae oe ae om oe we om am am oe em we em em om om ep om ee a th oe 


Checksum (cont. ) 1 


i Destination Address { 
----I[ aie ab an an an a a a a aa ee ae a ee ae a a a ee 


Destination Address (cont.) I 
oe ee a as pe aI a SE 


| Destination Address (cont.1 i} 
----II------ @------------------------ 


| Destination Address (cont.) {| 


2. Reliability 


Packet lengths as noted in the previous 
section are an important factor in 
reliability. If the packet is longer, 
it is more likely to experience errors 
in transmission. 

data transfer procedures in x.25 
level 3 provide for properly sequenced 
data packets exchanged in a flow 
controlled-manner between end points. 
The sequencing of data in the network 
layer also allows Us to eliminate the 
error recovery baggage needed in the 
transport layer to resequence the 


The 
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packets. This is a further shortening 
of the overhead obtained by the Vc 
approach. 

Another frequently heard cry is “What 
happens if a switch goes down ?"* In any 
network there would be a timeout 
followed by an error recovery procedure. 
In the case of a datagramme network 
there would be a new datagramme_ sent. 
In the case of an xX.25 network there 
would be Clear from the stations 
adjacent to the one in trouble. This 


would be followed by a Fast Seiect Call 
Packet. Since a definitive action has 
occurred, the network can decide how 
subsequent calls should be handled. The 
clearing cause and diagnostic codes 
provide the network status information. 
This information should be used to guide 
subsequent calls through the network. 


3. Ease of Implementation 


It is often suggested that it is “too 
much" to expect that a station or packet 
Switch maintain tables of active virtual 
circuits passing through. I think we can 


trust our’ small (and someday  large> 
switches to maintain tables of cail 
status. 

Programming an implementation of the 
network layer is only a step’ more 
difficult than the link layer of Ax.25 
Level 2. As a point of interest, Phil 
Karn’s (KAS9Q) implementation in the C 


language supports multiple logical links 
across one or more physical ports. The 
programming techniques needed at the 
network layer are almost identical to 
his approach to the link layer. 


4. Interoperability with Non-Amateur 
Networks 

The ability to use the same network 
layer procedures through interfaces 
between amateur and non-amateur networks 
would greatly simplify and expedite 
completion oof such facilities. These 
interfaces would provide the data 
equivalent of autopatch and reverse 
patch. The advantage of the data system 
over traditional voice telephone 
autopatches is the presence of the 
computer gear to validate authorized ham 
access to the facility. This will go a 
long way toward keeping the FCC happy 
about amateur control of a non-amateur 
access. 

The of 
usually 


addressing format x3121 Is 
found in xX.25. It defines 
formats for accessing the telephone and 
telex networks from packet switched 
networks. 

has source and 
facilities which 
conventions to. be 
There is no 


The xX.25 
destination address 
allows for address 
network or user specified. 


protocol 


addressing format in IP. The format and 


actual addresses allowed under TCP are 
assigned in groups of binary numbers. 
These have little or no logical 


relationship to the world an amateur is 
accustomed. 


5. International Acceptance 


The X.25 network layer has been 
impiemented in nearly every country. 
It is recognized and understood by most 
regulatory authorities and therefore 
lends itself to acceptance by those 
authorities for use in the amateur 
service. The U.S. DoD (remember : 
Department of Defense) may not be a big 
seller in other countries when a 
recognized international protocol is 
available. 

We in the United States have witnessed 
the impact we've had on packet -= radio 
worldwide. We must keep in mind the 
needs of amateurs abroad. Their 


cooperation is needed to provide transit 
network connections and uniform end-user 
protocols. 


THE TRANSPORT LAYER 

Ses a --a-- 

The transport protocol options before 
the amateur community are I150/CCITT 
X.224 and the U.S. DoD Transmission 
Control Protocol (TCP). Unlike their 
network layer cousins, these protocols 


have many similarities. 


During the late 1960’s and 1970's’ the 
U.S. Department of Defense (DOD) 
required networking standards for its 
own Advanced Research Projects Agency 
Network (ARPANET) . At this time the 
international standardization effort 
was just being to be envisioned and no 
formal acitvity had commenced. The DoD 


developed a set of protocols for use on 


ARPANET. 


During the last two study periods, the 


CCITT and ISO have developed the needed 
standards. The need for proprietary 
protocols for general network 
applications is no longer Justified or 


constructive for cost effective network 
development. X.224 provides for a range 
of network error recovery situations. 
It is divided into classes of operation. 
For this discussion we will address 
class 1. 


Class 1 is for use in networks with low 
undetected error rate, but having high 
rates of signaled failures. An amateur 
packet network using X.25 level 3 would 
certainly fall into this catagory. A 
packet network with IP as a level 3 
protocol would require X.224 class 4 or 
TCP to provide the needed error control. 
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The transport layer provides for several 
functions in the OSI model. They are: 


1. End-to-end data integrity; 
2. Network connection re-establishment: 


3. Re-synchronization after network 
layer reset. 

The same criteria used in evaluating 

network layer protocols will be used to 

help us through the transport _ layer. 

They are: 

1. Protocol Efficiency; 

2. Reliability: 

3. Ease of Implementation; 

4. Interoperability with non-Amateur 
Networks; 


5. International Acceptance. 


1. Protocol Efficiency 


The TCP and x.224 protocols are 
functionally similar, however X.224 is 
leaner and is better suited to the needs 
of the amateur network. By "leaner" we 
mean that it uses fewer bytes in its 
control header, thereby reducing’ the 
chance of error on the radio channei. 


The X.224 CR TPDU will usually contain 7 
bytes of overhead. 


The X.224 DT TPDU will have 3 bytes of 
overhead. 


A TCP message will usually have 20 bytes 
of overhead. 


Again we have a situation where the set-— 
up in the cCCITT/ISOQ protocol uses a 
longer header during the establishment 
phase in order to gain economies during 
data transfer. The X.224 class i 
connection request format is as_ shown 
below. 


X.224 Connection Request 


Ce nl ee ee ee ee 


~ me a a eee eee ee eee eee ee eee 


i Hengeh Indicator 
1 TPDU - CR | : CDT | 
| Destination Reference | 
eee imaidion Bareeenes (cont. ) | 
oceeitea Makecesees | 
i Source Scns, ee i 
| Class/options | 
; oo ee Data 
\ \ 


X.224 class 1 operation uses the 2. Reliability 


following format for data transfer: 
Both protocols are deemed reliable for 


X.224 Data Transfer amateur service. It should be noted 
SSS ee Se eee: a Sie ee a however, that TCP has a much _ larger 
overhead. Any additional functions in 
TCP that are not used in X.224 class 1 
A a A ee ee SA pei nae Se <= operation are just not needed given a 
| Length Indicator l VC-based network. 
| TPDU - DT j 
a td oe a a aha a a cela 3. Ease of Implementation 
{ Number Received l 
we ee meen meen nme nen ene Se ame ere a Implementation of either protocol would 
User Data 1 require the same general tasks. There 
\ \ are fewer implementations of X.224 at 
| 1 this time but this will change. I know 
2S a ea ae ae ee eS ee ea a ee of several completed implementations and 
many more are under development; It is 
The format of a_ typical TCP message projected to be more widespread than TCP 
would be as shown below. sometime during the 1986-87 time-frame. 
TCP Message 
wee oe 4, Interoperability with Non-Amateur 
Networks 
{ Source Port { There are implementations of TCP in most 
Ry ee ame eee fas a eas ec a Se ate Unix systems. Implementations of X.224 
l Source Port (cont.1 } are increasing in popularity. Even in 
we eee the U.S. DoD the CCITT/OSI protocols are 
j Destination Port | attaining new-found recognition. In the 
a ns acc he oh eee ae, la ae ae dieatra ere February, 1985 issue of Data 
{ Destination Port (cont.) { Communications Magazine, Jerrold S 
ee nee Foley wrote: 


ad i ee a ire ea, Sha od Alen ie ets "The U.S. Department of Defense (DOD) 


Sequence Number (cont.) i has been reviewing OSI protocols for 
Seti Se et ete es ee a suitability to its requirements. Since 
| Sequence Number (cont.) i both the DOD TCP <transport control 
Ca a ea at saa) Ra ae eee taeda et een ete ee protocol> and the OSI transport protocol 
I Sequence Number (cont. ) ] have strong ties to the Defense Advanced 
Sg eg ee AN Dh oP lesen ee aye au eet Research Projects Agency, the prospect 
| Acknowledgement Number of interoperability or REPLACEMENT (caps 
Se i at a a ASN ee ace aa a i ee nn a ea eat author) of TCP is_ good. The North 
| Acknowledgement Number (cont.) | Atlantic Treaty Organization has 
Pape ge Na nT Fe ame ee tegen ens ee OO ae ene eS eet indicated that OSI is central to its 
| Acknowledgement Number (cont.) | data communications planning." 
Acknowledgement Number cont.) | That is certainly interesting food for 
SS i===-S-= === thought... 
| Data Offset ji Reserved } 
P. hbeeeped te. eiepiees. Head e 5. International Acceptance 
ceyidasat Sd aye a ae TCP is being used world-wide on the 
Window | : : : : f 
De se Sacha fg Aen A ak at ache Eee ee chee Page ARPANET and in Unix mail applications, 
, but X.224 is being used to support a 
ae eee eee es Ne ee ns : great number of videotext terminals 
i ehetkeun —— se oe around the _ world. There are other 
classes of operation available within 


ae a a ae aw mh ae te ae ete te ty ee we es we ee te a ee ee ea 


} Checksum (cont.) i 


tn ate te ie ate ate ate af ate te ay ame ee cme eee at em me ei et at se ts 


X.224. They can be used with little 
change to the end user software if the 
need arises. One such application would 
be multiplexing many transport 
connections onto a single network 
connection. In this case the use of 
X.224 class 3 would be in order. 


ee et i ie te i ote te ore te me ee ee ee ee ee et at ts we wee te oe 


1 Urgent Pointer (cont.1 1 


ae em we ts ce ee ms we we ee eee es ee eee eee eee ee ee as aaa 


Overall, the protocols available from 


| 
\ \ 
| Data } 
\ \ 
: : the CCITT/ISO seem superior to those in 
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the DoD arsenal. The 
characteristics stand out: 


following 


1. Header Length 
In data transfer, the header length 
of a TCP/IP packet is at 
least 40 bytes. The header length in 
a X.25 level 31X.224 class 1 
packet is 7 bytes. 

2. Data Parsing in Packet Switches 


The TCP/IP header must be examined by 
each station in the path to ensure 
proper handling and routing. This 
increases switch overhead by 8-15 
times above that of the VC switch. 


3.U.S. DOD or CCITT/ISO 
NATO and the U.S. DoD have made 
statements of direction leading to 
the replacement of TCP with CCITT/ISO 


protocols on the ARPANET and _ the 
Defense Data Network (DDN). 

4. Virtual Circuit vs. Datagramme 
No commercial network offers 
datagrammes. Datagrammes were 
dropped from xX.25 during the 1984 


study period, 


S. Who has the knowledge to implement a 
VC based switch ? 
Existing amateur packet implementa- 
tions have more than demonstrated 


the availability of programming talent 
capable of implementing a VC-based 
packet switch. 


6. Packet Voice 
Packet voice 
implemented 


has been successfully 
over virtual circuit 
networks. The need to transmit data 
over a network in a short period 
of time is well handled by CCITT/ISO 
protocols. The British Telecom 
network Japan's KDD have 
throughput class implemented as a 
Standard offering and GTE Telenet 
will be Providing voice packet 
service in late 1585. 


and 


Interconnection with Public Data and 
Telephone Networks 

National and international intercon- 
nections to public telephone, data 
and teiex services will greatiy de- 
pend upon the use of internationally 


recognized protocols. 


8. Excess Protocol Baggage 
TCP offers error recovery from prob- 


lema which we should not have if we 
use a VC-based network protocol. The 
same error recovery is available 
from X.224, but 18s not a required 
function of all implementations. 
CONCLUSION 
Let suv understand that the marketplace 
has already made a stand which is 
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the packet switching industry, 
community and the standards 
Commercial and private packet 
networks are overwhelmingly 
Virtual Circuit (VC) based 
not datagrammes. This is not 
to say that the amateur community is 
bound to follow commercial standards, 


but it certainly tilts the scales a bit, 


driving 
user 
bodies. 
switched 
using 
protocols, 


The Radio Amateur Telecommunications 
Society wishes to continue in the 
direction of CCITT/ISO protocols. This 
direction was started over three years 
ago in Joint meetings with the Amateur 
Radio Developement Corporation. These 
meetings culminated in the ARRL’s 


adoption of AX.25 Level 2 as the amateur 
link protocol. This standard has done 
mugch to stimulate and direct packet 
radio activities to the more complex 
issues described in this paper and 
others in the procedings. We hope that 
the combined efforts of the amateur 
community will continue to yield great 
results in the future. 
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OFFER 

In keeping with its active support of 
CCITT/ISO protocols, the Radio Amateur 
Telecommunications Society (RATS) will 


send to interested parties copies of the 


protocol documents listed below. Call 
or write to make arrangements. RATS 
reserves the right to withdraw this 


offer at any time without notice. 


X.25 - Packet Switched Network Interface 
Specification 

X¥.200- Reference model of Open Systems 
Interconnection for CCITT appli- 
cations 

X.210-— OSI layer service definition con- 
ventions 

X.213- Network service definition for 
Open Systems Interconnection for 
CCITT applications 

X.214- Transport service definition for 
Open Systems Interconnection for 


CCITT applications 


X.215 


X.224- 


X.225- 


X.2440 


X.250- 


Session service definition for 
Open Systems Interconnection for 
CCITT applications 


Transport protocol specification 
Open Systems Interconnection for 
CCITT applications 


Session protocol specification 
Open Systems Interconnection for 
CCITT applications 


Procedure for the exchange of 
protocol identification during 
virtual call establishment on 
packet switched public data 
networks 


Formal description techniques for 


data communications protocols and 
services. 


Diagramme 1 


OPEN SYSTEM INTERCONNECTION REFERENCE MODEL 


Level END USER A END USER B 
WcAppidestient 4 .ess5Steeteese sees > 1 Application | 
gD Presentation i <2Senseeeceedsesess > 1 Presentation | 
5 i Saosin ~ a EE ESS ee aS > t Session i 
4 | ® TRANSPORT #10 ¢ > [ + TRANSPORT *| 
re! et EOE? 4 a ae eR eS Dee > {| * NETWORK #* i 
Z cae i i la eR a > i Link i 
if enyical. 4 Co ees SE ee, Ee > I Physical { 
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Diagramme 2 


Protocol 


ee 


Exchange: 


te ie ee 


X.25 Level 3 


Station B 


mm mn 


- 


Destination 


~—_m—_nae ee eR DOD een eee ee ee Oe ee ew eB ewe ew ee eee eee eee eee eee eee ee ee eee 


¢g€-- 
Data 0 
Data i 


Accept 
a= > 
=> 


Data 2 --> 
<-- RR O 


Data 3 ~--> 


<-- RR 2 


q-- 
Clear 


RR 3 
--> 


€-~ Clr cCfm 


--> 
--> 


Data 0O 
Data 1 


RR 0 
~-> 


<-- 
Data 2 


<-- RR 2 


<-- RR 3 


Clear --> 


€-- Clr cCfm 


~-> 
--> 


Data 0O 
Data 1 


<-- RR O 


Data 2 <--> 
<-- RR 2 
--> 


Data 3 


<-- RR 3 


Clear ~-~-> 


<€-- Clr Cfm 
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--> 
Accept 


Call 
Coa 


Data 0 --> 
<-- RR O 
Data 1 --> 


Data 2 --> 
<-- RR 2 


Data 3 --> 
<-- RR 3 


Clear --> 
<-- Clr cCfm 


Diagramme 3 


Protocol Exchange: Internet Protocol 
Source Station A Station C Station B Destination 
Data 0 <--> 
Data 1 -+-+> Data 0 ~=~> 
Data 1 s--2ee-4e2--7-° weceees> 
Data 0 <-~> 
Data 0 -+> Data 1 <-~> 
Data O --> 
<-- ACK O 
<~~ ACK 0 
<-- ACK O 
€-- ACK O 
€+~ ACK 0 


Data 2 «+> 
Data 2 -~-> 
Data 2 ~~> 
Data 2 ~-3 
Data 2 ~~? 


<-- ACK 2 
<€-- ACK 2 
<€-- ACK 2 
<+- ACK 2 
€-+- ACK 2 
Diagramme 4 
X.25 Data Packet 
{ GFI } LCGN \ 
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Introduction 
-B--o a 


The purpose of this Numbering Plan is to 
facilitate the introduction of amateur 
data networks and provide for 
internetworking in the North American 
region. 


1.0 Design Considerations 


1.1 This proposal does not require, nor 
preclude, governmental involvement 
in network administration. 


1.2 The Regional Numbering Plan should 
permit the identification of a cal- 
led country as well as a _ specific 
network and station. 


1.3 The Numbering Plan should provide a 
consistent addressing format when 
connection is made with or through 
commercial telephone networks. (i.e. 
telephone, telex, data networks.) 


1.4 A national number assigned to a 
terminal should be unique within a 
particular network. This national 
number should form part of the 
international number which’ should 
also be unique on a worldwide 
basis. 


1.5 Specific national numbers should be 
easily determined. 


1.6 National Numbers’~ shouid require 
minimal administrative overhead to 
network management and users. 


2.0 Numbering System 


2.1 The i0 digit numeric character set 
O-9 should be used for numbers (or 
addresses> assigned to terminals in 
the amateur network. This 
principle should apply to both 
national and international numbers. 


2.2 Use of the numbering system as 
outlined in 2.1 will make it pos- 
sible to interwork with terminals 
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on public telephone, telex and data 
networks. 


Prefix Codes 


The Prefix Code will signify the 
type of network indicated by the 
remaining digits. 


The Prefix Code will be the first 
digit and should be coded as 


follows: 


Amateur Packet Switched Network 
Public Packet Switched Network 


\__. Reserved 


Telex Network 
Telephone 


Data Network Identification Codes 


All Data Network Identification 
Codes shall consist of four digits. 


Each country in the region shall 
use the codes listed below. 


Canada 

United States of America 
Puerto Rico 

Virgin Islands (USA) 
Mexico 


National Number 


The National Number shall consist 
of up to 10 digits. 


Each National Number shall be 
unique within the country. 


5.3 The National Number shall contain a 


three digit area code. 


S.4 This number shall correspond to the 


5.5 Additional 


5.10 
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North 
for 


the 
Plan 


area code used in 
American Numbering 
Telephone Networks. 


addressing information 
may be provided in an address 
extension facility containing the 
amateur callsign and SSID. 

If full 10-digit addressing is 
desired, the number corresponding 
to the local exchange and 
subscriber line may be used. 


If no number is available or if 
additional numbers are required 
they should be assigned using ex- 
change numbers in the range of O00 
through 199. 


The assignment authority for these 
exchange and subscriber numbers is 
limited to the Network Coordinating 
Agent for that area. 
Service Codes 011, 111, 211, -311,; 
411, 511, 611, 711, 811, 911 are 
reserved pending definition by the 
local Network Coordinating Agent. 


The exchange code O00 is reserved 
for internal network administration 
and assignment authority is limited 
to the National Network 
Coordinating Agent. 


The exchange code 555 is reserved 
for internal network administration 
and assignment authority is _ limited 
to the local Network Coordinating 
Agent. 


The exchange and subscriber code 
555-1212 is reserved for regional 
directory service. Assignment 
authority is limited to the _ local 
Network Coordinating Agent. 
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International Number 


6.1 The International Number shall con- 


Sist of the DNIC and the National 
Number. 

6.2 Each National Amateur Network will 
be capable of interpreting the 
first four digits of the Interna- 
tional Number. This is needed to 
facilitate routing between 
networks. 


6.3 The use of the DNIC by 


stations in 
transit countries would serve as a 
ready reference for checking third- 


party traffic—handling require— 
ments. 
6.4 The International Number May op- 
tionally include a prefix code. 
7.0 Formats 
7.1 Amateur Network Number Format 
P-—DDDD-—-AAA-—-EEE-NNNN = 15 
DDDD-AAA-EEE-NNNN = 14 
7.2 Amateur Network Number Format 
(alte mate) 
P—DDDD-AAA = 8 
DDDD-—-AAA = 7 
Where: 
P = Prefix digit 
D = Data Network Identication Code 
A = Area Code 
E = Exchange 
N = Number 
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Abstract 


With the increasing traffic appearing on 
local two meter packet radio channels, computer 
packet radio message systems pi sete to-the casual 
conversationalist typer as channel hogs. The 
message systems interfere in two modes. -First, a 
typer user connects with it and downloads large 
packets of file data, help messages, directory 
etc. Second. a semi-automatic store and forward 
mode is invdked periodically to forward messages 
further up the network to other messages systems. 
The service these message systems provide 
more than justifies their existence, so the answer 
is not to ban them. A new method might alleviate 
the interference and retain their useful features. 
This method involves frequency see ae G the 
ability to switch frequencies on command, 0 pass 
rat bac, 


Introduction 


In the coming year, 9600 baud ae radio 
backbone network traffic passing on 220 MHz will 
remove the message computer interlinking from the 
main local area channel. This will alleviate 
interference only ces The casual typer will 
still want to read the bulletin board oufput and 
thus cause heavy contention for other typer-to- 
ryDee conversations. The basic concept is then 
that the casual typer, upon connecting to one of 
these message syStems. commands the system to 
switch frequency to w'ork with the typer. The 
message system automatically returns to the local 
area calling channel upon disconnect or timeout 
for lack of typer user activity. 


The Basic System 


The Xerox 820 has proved itself to be a 
valuable addition to the packet radio inventory. 
A small hardware addition (see AMRAD Newsletter 
Nov/Dec 84) allows packets to be sent and received 


from the onboard S]M. Using software developed by 
Phil Karn, KA9Q, it serves as a Terminal Node 
Controller (TNC) and digipeater. Using software 


developed by Jon Bloom, KE3Z, it serves as a two 
port digipeater, a novel device linking two packet 
channels. Various amateurs have written good 
message system software, the most famous includes 
interlinking provisions for middle of the night 
transfers between ssystems. Software and hardware 
have been developed to enaler the frequency of a 
two meter tramscéiver using the Xerox 820 user ea 
parallel port. (see Amrad Newsletter, February 85). 
marriage of some of this software would allow a 
frequency agile message system which would help 
alleviate congestion on the local area two meter 
packet channel. 


Concept of Operation 


Picture the scenario in which packet radio 
user David wishes to communicate with user Howard. 
Using standard packet techniques a connection 
with user Howard is requested on the local 145.01 
MHz two meter local area frequency. Howard is 
working late and thus does not answer David s “SABM 
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frames which fall on the ground unserviced. David 
is not thwarted however. He connects with Tom's 
message system, intending to leave a message for 
Howard to be read later. Instead of the usual 
carriage return from David producing the torrent 
of characters from Tom's message system, the 
system requests David to indicate the desired 
frequency of operation. The frequency is entered 
b avid and Tom's message system shifts frequency 
es to pass and recéive traffic from David. 
David then commands the message system to switch 
frequency to 14ADA wone the coordinated 
alternate packet frequencies in David's area. The 
message system changes to the new frequency and so 
does David. When David is done using Tom's 
aye tat szne disconnects ang k e system reverts to 
the local area frequency 45.01 to await the next 
user. Old NTS users will recognize this classic 
scheme where a user checks into the net on net 
frequency and moves off frequency to pass traffic 
returning when finished. ongestion on the local 
area typer-to-typer frequency is thus reduced. 


Hardware Required 


To put this concept into operation requires 
the following hardware: 


2) Xerox 820 Computer Boards. 
2) 5 1/4 inch Floppy Disk Drives (one each board) 
2) Power supplies 
2) Keyboards 
2) CRT Monitors . 
1) Packet Interface Board (State Machine) 
1) Freqvency Utontrol Interface Board (optional) 
1) ICOM IC-2AT Transceiver modified 
1 ell Standard 202 Modem'and ICOM interface: 
600 ohm transformer, resistor and transistor) 
The packet interface board contains a state 
machine (prom and latch) for receiveing NRZI 


encoded frames and recovering clock as well as a 
divider and aes flop. for: tCransmiteing=: NRAL 
encoded data. It is completly described in the 
referen fe article. The cost of this device is 
about § 5 and several have been built in the 
Washington area. A printed circuit board is 
ees and may be available in the future from 
om Clark, W3IWI. 

The Ered ey control interface board is 
optional as all that is really required is to add 
a socket to the ICOM IC-2AT anda cable to the 
Xerox 820 acting as the TNC. The board contains a 


sehen’ display which shows the new frequency 
selected by the computer. 


The interconnection of this hardware is 
as follows: The acket interface board is 
connected between the modem and the Xerox 820 TNC 

IO port A; The frequency control interface board 
(or ust a cable) is connected between the Xerox 
20 TNC user PIO port and the ICOM IC-2AT; A 
serial cable connects Xerox 820 TNC SIO port B and 
the Xerox 820 Message System SIO port A; One 


ower supply and one epey disk drive is provided 
Por each peiex and each has a CRT and keyboard. 


Software Required 


_ The FAMS requires each Xerox run the CP/M 
disk operating system. aa une Phil Karn 
TNC code runs in the X@Ox820TNC. Any message 
system software you desire runs in the Xerox 820 
Message System computer. The modifications to 
Phil Karns code allow command of the PIO port and 
setting of the ICOM frequency. In addition, Port 
B software of the Xerox TNC has been modified to 
allow terminal operations and this connects to the 
Xerox820 Message System cornputer when a packet 
connection is achievéd on Bort 4. 
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Complete Further Details 


Articles and software mentioned in pee a er 
are obtainable from AMRAD, P.O. Drawer 6148, 
McLean, VA USA 22106-6148. Request.s for software 
should be accompanied by two 5 1/4 inch floppy 
disks or one 8 inch oon Pl Each month, AMRAD 
publishes a newsletter containing information on 


peckee radio: topics: and other amateur radio 
echnical pursuits, such as spread spectrum 
digital speech and deaf communication. Contact 
the above address for details on membership and 
newsletter. 
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EASTNET: 


A Year Later 


Bob Bruninga WB4APR 
59 Southgate Ave 
Annapolis, MD 21401 


The original goal of EASTNET to link 
the eastern seaboard from Washington DC to 
Boston was met more or less on August 6, 
1984 when packets were exchanged via the 
repeater path WB4APR-6 in Elk Neck 
Maryland, WA2LQQ-O in Warwick NY, WORLI-O 
in Westford MA, and kKD2S-1 in Lowell MA. 
Since that time numerous alternate paths 
have been exercised but the saturation of 
the primary link frequency of 145.01 MHz 
during prime evening hours has prevented 
routine end-to-end multi-hop paths. 


About the time that saturation of 
145.01 MHz occurred, the emergence of WORLI 
type bulletin boards based on the XEROX 820 


system brought about a new pattern of 
operation which helped ease the multi-hop 
loading. The WORLI bulletin board systems 


(PBBS’s) include an auto-forwarding feature 
which allows the PBBS’s to update each 
other with messages destined for 
individuals homed on their local PBBS. By 
programming these PBBS’s to auto-forward on 
the link frequencies during non prime time 
hours, the need for long distance multi-hop 
exchanges was minimized. Individuals with 


messages for adistant user need only post 
the message on the local PBBS and at the 
same time pick up his mail using a_ direct 


path or at most a single hop connection. 
So the result of auto-forwarding is a two 
fold reduction in link traffic by 
encouraging all messages to be posted on 
local paths, and forcing the multi-hop 
regional forwarding to occur during off 
hours. 

The next step in relieving congestion 
on 145.01 is to make the PBBS s frequency 
agile so that they are available to local 
users on alocal frequency such as 145.05 
during prime time and move over to 145.01 
only during off hours at scheduled periods 
for auto-forwarding. In EASTNET we have 
already moved the WB4APR-5 HF BRIDGE system 
over to 145.05 and the local PBBS of KS3Q 
over to 145.09. The W3IWI PBBS remains on 
145.01 to serve the link traffic until 
frequency agility has been achieved. 


HF activity is Stabalizing on 
10,147.900 KHz with the WB4APRO bridge into 
Washington, K7PYKO into Tuscon, W9TDO into 
Chicago, and WORLIO into Masachusetts. 
K7PYKQO shifts between 20M and 30M as 
conditions dictate and WORLIO comes up when 
time permits. 


At a recent roadside gathering of 
enthusiasts from Virginia, Maryland, 
Pennsylvania, and New Jersey, the 
Mid-Atlantic Packet Repeater Council 
(MAPRC) was formed to allow a_ unified 
representation of regional packet 
interests. An arbitrary territory of 100 


miles radius about the primary link 
digipeater of WB4APR6 was chosen as_ the 
area of responsibility. A similar group, 
the Tri-State Packet Repeater Council 
(TSPRC) has recently been formed to cover 
Northern New Jersey, New York, and 
Connecticut. 


To encourage use of 220 MHz we will 
soon be putting a 221.02 MHz piggy-back 
radio on the WB4APR-6 digipeater. The 221 
MHz transceiver will be connected to the 
same TNC but will also be under subtone 
control to link directly to 145.01 avoiding 
the digipeater for stations which are so 
configured. The subtone control frequency 
is the reverse channel tone of 367 HZ which 
is already built into most 202 modems. 
Another possibility is the use of dual port 


software which is just becomming available 
to allow a XEROX 820 system to serve both 
channels. Our plans still include a number 


of wideband channels and narrowband 
channels according to the following plan: 


220.55 221.007 
220.65 221.02 
220.75} wideband 221.044 narrow band 


220.85} 100 KHz 221.06}; 20 KHz 


220.95 221.08. 


Note that this is the same as what we 
proposed last year except that the narrow 
band channels have moved down 10 KHz to 
match the existing 20 KHz channel spacing 
on the band. 


On the following maps all of the known 
wide area use packet repeaters are 
indicated as well as the PB8S’s and gateway 
stations. Indications of 220 activity 
should be considered to be in addition to 
the existing two meter operations at the 
same location. These maps are not expected 
to be 100 percent accurate and we 
apologize for all those who were omitted 
but we just wanted to give a quick overview 
of packet activity in various areas of the 
country. We will attempt to update these 
maps periodically and make them available 
next year if you will help by forwarding 
any permanent updates to the above address. 
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PACKET RADIO TIMING CONSIDERATIONS 


David Engle, KE6ZE 
1063 Summerwood Ct. 
San Jose, CA 95132 


ABSTRACT 


This Paper presents an analysis of 
existing packet radio systems and equip- 
ment (2 Meter AFSK). Both dual and_ single 
frequency repeater efficiencies are 
analyzed. The results demonstrate the 
relative inefficiencies of the existing 
networks. These inefficiencies reduce’ the 
effective capacity of a 1200 baud channel 
to 300-500 baud. In order to correct some 


of these inefficiencies a few suggestions 
are offered. 
INTRODUCTION 

A packet radio network stat ion in 
switching from receive mode to transmit 


mode passes through several processes that 
consume Significant periods of time. 
These losses are due to inefficiencies 


contributed by the sending station, the 
repeater, and the protocol utilized. In 
order to establish a basis for further 


investigation, these time consuming 
processes and activities are explained 
here: 

1. Send process time -- The time_ the 


sending station’s central processor 
(cpu) takes to assemble and dispatch 


the packet. This is the terminal 
node controller (TNC) processing 
time. The time consumed is approxi- 


mately .250 milliseconds. This’ time 
is relatively insignificant (in pro- 
portion to the other processes) and 


for all practical purposes can be 
ignored. 

2. Transmitter turn-on time -- The time 
the sending packet radio_ stat ion 
takes to turn on it’s carrier 
(and/or switch to transmit from 
receive). This activity is often 


overlooked in the analysis of packet 


radio systems. It is the single 
largest piece of dead time in the 
packet transmission process. This 


time is not of any great concern in 
a voice system and is not’ generally 
not iced for what it is. However, it 
can be recognized sometimes on voice 


as an operator chops off his call 
sign announcement at the beginning 
of each transmission (Sound fami- 


liar? You always thought he started 
talking before he pushed the PTT 
button). The amount of time consumed 
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by this activity can vary signifi- 
cantly. A transmitter altered 
specifically for packet radio ser- 
vice can come on line in several 


milliseconds (e.g., like CW break-in 


keying). Most amateurs are using 
commercial two meter equipment. 
Unfortunately, most twc meter equip- 


ment is not made for break-in keying 
and suffers from the following list 
of delays: 


a. Synthesized rigs have to allow 
time for the phase lock loop 
to acquire the transmit  fre- 
quency when switching from 
receive to transmit. Experi- 
ence has shown’ some rigs to 
require 500 milliseconds’ for 
this function. 


sol id 
and tube 
have to allow 
time for the transmit power 
supply to come on line. This 
act ion can take as little as 
100-200 milliseconds but 500 
milliseconds is more realis- 
tic. 


Older rigs with state 
receivers 


transmitters 


Older rigs with relay switch- 
ing of the antenna can use up 
to 200 milliseconds to accom- 
plish T-R switching. The time 
is used in circuit delays, 
transmit recovery and_ relay 
movement time. 


d Low powered rigs usually use a 
solid state in-line amplifier 
(brick). These units switch 
from receive (bypass mode) to 
transmit by sensing for RF 
energy. Upon detection of RF 
from the rig the PA unit 
switches in the high power 
amplifier. The time for this 
function to take place has 
been found to require about 
200 milliseconds. 


Modem turn on time -- The time a 
modem takes to enable and stabilize 
the initial tone. Most commercial 
units allow 50 milliseconds for this 


event. The time consumed by this 
event is usually masked by the 
transmitter turn on time, SOit can 


be ignored 1M mos: cases. However, 
if the system waits for clear to 
send (CTS) to be returned from the 
modem before turning on the 
transmitter, this unnecessary delay 
will be introduced. Each acket 
radio stat ion should be checked to 
insure the modem and _ transmitters 
are turned on simultaneously. A 
modem constructed specifically for 
packet radio use can eliminate this 
time. 

Propagation time -- The time it 
takes the radio signal traveling at 
the speed of light to arrive at’ the 
receiver. A nominal distance of 30 
miles will take .03 milliseconds to 
traverse. For all practical pur- 
poses this time can be ignored. 


Receive process time -- The tine it 
takes the receiving station to pro- 
cess the packet and pass it on to 
the next stage (e.g., operators ter- 
minal). An allowance of .25 mil- 
liseconds should take care of this 
function. Once again for all practi- 
cal purposes this time can be 
ignored. 


Data receipt allowance -- At the end 
of transmitting a data packet the 
transmitter and modem do not’ turn 
off coincident with the last bit. 
Commercial modems cont inue to 
transmit the final tone for 10-20 
milliseconds after the last bit. 
This is to allow the receiver clock- 
ing mechanism time to move out the 
last character received prior to the 
introduction of line noise that will 
occur with the removal of the car- 
rier. 

Transmitter turn off time -- Some 
hand held transceivers do not stop 
transmitting with release of the 
“PTT”. They hang for a short time. 
While not a common occurrence it can 
revent TNCs with carrier detect 
rom accessing the channel. Thus, 
ack packets could be delayed. 
Reports of this happening have _ been 
seen on the UNIX USENET. This has 
not been seen the S.F. Bay Area _ and 
isn’t included in the _ following 
analysis. 


These are the inefficiencies introduced by 
the packet boards, modems and RF equipment 
into a packet radio network. 


Another class of inefficiencies’ are 
introduced into the network by the 
AX25/HDLC protocol utilized by the _ net- 
work. They are: 

1. Protocol overhead -- The HDLC and 

AX25 sync, control, address, and 


checksum bytes add an additional 20 
or 27 bytes to each packet. They 
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are: one sync byte (beginning), 14 
or 21 bytes of address (14 for sim- 
plex, 21 for repeater), two control 
bytes, two checksum bytes, one sync 
byte (end). 


Bit stuffing -- 
required by the HDLC protocol 
requires that a "0" bit be inserted 
each time five "1" bits are encoun- 
tered. The random probability of 
this occurring is 1 in 32 or 3.125%. 
This means that the data stream will 
be expanded approximately 3%. Table 
1 includes transmit times for 3 
packet sizes adjusted for bit stuff- 
ing. 


Bit stuffing 


Acknowledge packet -- Each message 
is usually acked. A receiving sta- 
tion sends back to the sender an ok 
to proceed packet of 20 or 27 bytes 
(20 for simplex, 27 for repeater). 


The protocol itself introduces a quantity 
of bytes and an additional 3% of overhead 
(delay) into the system. 


REPEATERS 


The key to any packet radio system is 
the repeater. There are two types of 
repeaters in general use, single frequency 
and dual frequency repeaters. On a singl 
frequency repeater (a digipeater), th 
repeater receives the entire packet, makes 
sure the packet is valid, and retransmits 
the packet on the same frequency. A dual 
frequency repeater listens on one fre- 
quency and retransmits the packet on 
another frequency. It does this with no 
delay and thus no packet validity check. 
Each approach has its merits and detrac- 
t ions. On the surface it appears as though 
a single frequency repeater utilizes half 
the bandwidth of a dual frequency repeater 
but takes twice as long to complete a 
transaction. However, the inefficiencies 
described above cloud the issue and_ the 
merits are not as clear as they seem. 


e 
e 


Another point of concern in a packet 
radio system is the amount of data to be 
allowed in the packets i.e., the packet 
size. With a given amount of data to send 
a few large packets would be more effi- 
cient than many small packets. But if you 
have a small amount of data to send then 
you are wasting the capacity of a large 
packet. The solution appears to be to use 
variable size packets. Then a maximum 
packet size has to be agreed upon, as all 
members of a local packet community have 
to be able to receive that maximum _ size 
packet. 


It should be noted that Abramson and 
Ferguson have theoretically shown that 
mixed packet sizes decreases the 
throughput capacity of a contention packet 
system. However, for better or worse’ the 
current packet radio systems allow mixed 


packet sizes. As some packet systems are 
now running close to their capacity this 
effect is now being realized. Mixed packet 
sizes and the relative decrease in channel 


capacity is an effect that should be 
investigated. 
INVESTIGATION 

In order to determine the effect of 


these inefficiencies on packet radio tran- 
sactions a few types of transact ions are 
examined. They are for: a simplex connec- 
tion, a connection through a Dual Fre- 
quency (DF) repeater and a connection 
through a Single Frequency Repeater (SF), 
Packet sizes examined are a 64, 128, and 
256 bytes of data on an Amateur radio 
packet system operating on a typical two 
meter AFSK FM carrier utilizing i300 baud 
AT&T type 202 modems. The data packets 
conform to the AX-25 protocol. Fach data 
packet is individually acknowledged and 
the ack packet is a minimum packet of 20 
or 27 bytes. The times are based on the 
actual measured times of the KE6ZE & KA6M 
stat ions and the KA6M repeater. These 
delays are depicted in Figure 1 and Table 
2 


Utilizing the data in Tables 1 and 2 
the efficiencies can be computed. The 
results are presented in table and  gym- 
marized in Table 4. The efficiency is the 
time consumed by the actual data packet 
(of 64, 128, 256 Bytes) divided: b the 
time utilized for each transaction. (Kxam- 
ple for a single frequency repeater and 64 
bytes of data: 1781.62 + 4389 + 489 
2659.62, 439 / 2659.62 -16506 or 17%. 
Have to add two 64 byte transmission times 
because the data was sent twice, once to 
repeater, then repeater’ to destination 
(see Figure 2). Note: Table 3 accounts for 
the other multiple hop times.) Notice the 
the two dual frequency efficiencies. The 
first is calculated on an elapsed tine 
basis, the second on a spectral density 
time basis. This is to relate the two 
repeater types on an equal basis. 1.e.: 1 
a single frequency transmitter utilized 
twice the data rate and thus twice the 
bandwidth then the two would be equal in 
spectral density. 


Note the decreased efficiency of the 
smaller packets. This’ is one case where 
bigger is better. Also, both repeater 
types are relatively inefficient at the 
small packet sizes utilized in most packet 


radio systems at the present. It appears 
as though we have considerable room for 
improvement in our systems. Note the 


advantage a single frequency repeater sys- 
tem offers in its ability to allow users 
to direct connect. At 25% efficiency a 
1200 baud system will have the throughput 
rate of 300 baud. 


CURES AND FIXES 
What can be done to 


reduce some of 
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these inefficiencies? One thing is_ to 
improve the data stream transmitted over 
the ether. A single frequency repeater can 
offer efficient use direct connects to its 
users, while having the repeater available 
should it be required. Make bigger  pack- 
ets where possible. But not too big, there 
will be both rag chewing traffic and com- 
puter traffic, each at opposite ends of 
the packet size needs. Attention to modem 
timing can increase efficiency also. 


Another opportunity is to improve the 
rig for packet radio. The choice is to 
either make or buy a rig, but believe it 
or not the best may be to buy a used rig. 
There are old mobile FM voice rigs _ that 
are suitable for 2 meter packet radio ser- 
vice. They are generally available used at 
reduced prices and should have the follow- 
ing characteristics: 


Crystal controlled receiver with 
another crystal for control of the 
transmitter frequency. 


All solid state unit with an 
integrated single power supply. 
Although some hybrid rigs with solid 
state receivers and tube 
transmitters are more likely to _ be 
found. These have been found to come 
on in about 200-300 milliseconds. An 
all sol id state can be cut down to 
less than 100 milliseconds for turn 


on. 


1. 


Moderate power RF amplifier con- 
tained within the rig. i.e., try to 
keep from using an external amplif- 
ier. 


Antenna switching handled by a_ reed 
relay or PIN diode blocking (PIN 
diode is the best of the two). 


Fortunately enough __ there are older 
(obsolete ?) rigs with most of these 
characteristics. They are crystal  con- 
trolled mobile rigs. Progress in technol- 
ogy for voice rigs has’ relegated’ these 
units to the storage shelf and/or flea 
market sales. If you are looking to buy a 
rig and devote it to packet radio at your 
next flea market look for an_ all sol id 
state, crystal, mobile rig. For packet 
radio you rarely need more than _ several 
frequencies. So, the limited channel 
selection should not be a disadvantage. 
They are small and can be easy to shoe 
horn into a mountain top site. However, 
they have moderate power output (10 watts 
or so>. If they can be used bare-foot they 
make a fine packet station. 


There are also lots of handy-talky 
(HT) units available at flea markets. 
Generally HTs have disadvantages of not 


having enough power and/or being’ syn- 
thesized. If your repeater or stat ion is 
operating simplex then the PLL lock time 


may not effect transmitter turn on _ time. 


It depends on whether or _ not the unit 
always waits for a time to lock or 
PLL lock. The lock time -in addition to an 
outboard linear switching time was_ enough 
to require the first KA6M repeater 500 
milliseconds for transmitter turn on time. 
The temptation to make a small packet sta- 
tion using an HT is great. If you build a 
repeater (or station) with a low powered 
HT or mobile rig and a linear, be sure to 
key the linear from the TNC PTT. Don’t use 
RF sensing to switch the linear. 


Also available at Flea ee are 
older commercial mobile S 
Motorola Motrac). These hybrid ce id 
state receiver, tube transmitter) rigs can 
be utilized in packet service if one gives 
consideration to the power supply turn on 
time required by them. Careful attention 
and adjustment can get them down to 150- 
250 millisecond turn on time. They have 
the advantage of 25-50 watts of power and 
good reliability. The lack of more than a 
dual frequency control may hamper versa- 
tility at home but for a_ bulletin board 
system they may be ideal. 


CONCLUSION 


A packet radio system has_~ delay 
introduced by all its component parts: the 
originator, the repeater, and the reci- 
pient. The key item is the repeater. The 
repeater should have the most attention 
given to it in elimination of dead time. 
Practices incorporated into repeaters as a 
result of voice techniques should be re- 
examined. As the transmissions are _ not 
intended for the human ear the repeater 
can be tailored for efficiency. These 
tailorings are: 


1. Eliminate the squelch tail on a_ two 
frequency repeater. Holding the car- 
rier on may keep other’ transmitters 
from utilizing that time. 


2. Key the transmitter on a_ two _ fre- 
quency unit from a tone detection on 
the receiver side. This will keep 
intermodulation product interference 
down and also drive the kerchunkers 
crazy. 


3. In a two frequency repeater key the 
transmitter immediately upon tone 
detection. Or upon carrier detection 
if tone detection is not used. Some 
voice repeaters require a signal be 
present for a_ short time prior to 
keying the transmitter. For digital 
use this should be eliminated. 


4. Strive to incorporate as many as 
possible of the previously described 
transmitter features into the 
repeater. 


5. Turn the squelch up on the receive 
system. The data will be lost on a 
noisy signal anyway. 


senses. 


6. Have the CW IDer use one of the 
modem tone frequencies. This will 
allow channel busy detection schemes 
using tone detect rather than car- 
rier detect from having data colli- 
sions. 


7. Have the CW IDer come on at the end 
of a transmission in a two frequency 
system. This will keep from clobber- 
ing a data packet transmission on a 
start up. after 5 minutes has 


elapsed. 


Paying attention to the repeater can reap 
significant benefits to all the partici- 
pants in a packet radio system. Elimina- 
tion of a unit of time from the repeater 
will save two units of time on a_ transac- 
tion: once on the data packet, and again 
on the acknowledgement packet. 


Round up an oscilloscope and_ check 
your packet radio system. After gathering 
measurements on your system run through a 
calculation set as done here. Doing this 
you will probably find out what it is that 
is causing your 1200 baud system to act 
like a 300-400 baud system. Don’t think 
that other digital communication schemes 
are much better at efficiencies’ either. 
AMTOR Baudot RTTY communication starts off 
at 63% efficiency (5 data bits and 3 over- 
head bits for each element) then the AMTOR 
overhead starts wearing that down. 


CLOSING COMMENTS 


closing, there are 
numerous theoretical studies of packet 
radio systems in various technical jour- 
nals. These studies in general do not 
account for all of the delay types listed 
in this paper. When analyzing your packet 
radio system by these studies don’t ignore 
these practical effects. In particular, 
transmitter turn-on time can cause diffi- 

culty in carrier detect protocols such as 
utilized on the VADGC and TAPR boards. The 
value of the carrier detect is somewhat 
diminished by the time it takes to turn on 
a carrier e.g., after a station senses the 


Finally, in 


medium for carriers and prior to turning 
on its carrier a_ significant amount of 
time can pass, during which another 


(undetected) carrier may appear. Analyses 
of system stability, bandwidth capacity 
and packet delay should take this factor 
into account. 


64 Bytes = 4389 milliseconds 

128 Bytes = 879 milliseconds 

256 Bytes = 1758 milliseconds 
Table 1 


Time to Transmit Data 
Includes 3% Bit Stuffing 
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Simplex 
Direct 
Connect 


——_— S| 


me eae 


XZ 
797.06 


Dual 
Freq 


Repeater 
N p 


15 


a oo 


oT 


—s 


Single 


Freq 
Repeater 
225 Transmit Process Time 
x25 Repeater Process Time 
Modem Turn On Time (masked by next item) 
250 Transmitter Turn On Time 
250 Repeater Transmitter Turn On Time 
180 AX25 Overhead (20/20/27 bytes @ 1200 baud) 
180 Repeater AX25 Overhead (27 bytes again) 
Data Transmission (see table 2) 
Data Bit Stuffing 3% (see table 2) 
ilps Data Receipt Allowance (carrier hang on) 
15 Data Receipt Allowance for Repeater 
e034 Propagation Delay 
303 Propagation Delay for Repeater 
125 Receiver Processing Time 
890.81 = Time to transmit an empty (or control) packet 
from source to destination. 
x2 
1781.62 = Time to transmit an empty packet (source to 


destination) and ack it (destination to source) 


Table 2 


Times of the component parts of packet transmissions. 


Times in Milliseconds 


Simplex, Direct Connect 


tae te ey ce eet ei ei ee ee ee eee ee ee re eee 


64 128 25.6 
1236 2555 1676 = Milliseconds 
36% 69% 52% = Efficiency 


Dual Frequency (Voice) Repeater 


eee ee ee ee eee ee ee ee eae ae eee eee 


64 128 256 = Bytes of data 
2236 2676 3555 = Milliseconds 
20% 333 49% = Efficiency 


Single Frequency (Digital) Repeater 


64 128 256 = Bytes of data 

2660 3540 5278 = Milliseconds 

17% 25% 33% = Efficiency 
Table 3 


Complete Transactions of Varying Packet Sizes 


Times In Milliseconds 


128 256 = Packet size 

25% 33% = Single frequency efficiency 

33% 49% = Dual frequency efficiency 

16% 25% = Dual frequency spectral efficiency 

52% 69% = No repeater direct connect efficiency 
Table 4 


Channel Data Rate Effective Utilization Efficiency 
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Introduction 


This paper presents a pees biased view of 
the main two types of networking concepts being 
discussed for amateur radio. 


Overview 


Amateur packet radio made a major 
breakthrough last year. After a couple years of 
development, a standard has been adopted for 
point-to-point packet communications, often 
referred to as the Link Layer, or Level 2 of the 
ISO reference model. 


Even as work was being completed on the 
link layer, amateurs were beginning to take on the 
challange of designing a true amateur packet 
network system. Two "camps" have taken shape in 
this stage of development work, the 'Virtual 
Circuit' camp and the Datagram' or 'TCP/IP' camp. 
Both groups are working on software, and I believe 
both wal be used for a period of time to see 
which is best suited for amateur packet radio. 


One thing both groups generally agree on is 
that what must be provided by the amateur network 
is a method of dae | data from a source to a 
destination fairly re ey Both groups agree 
that this should be assured by a transportation 
device at each end of a communication path, and 
that this communications path be absolutely 
reliable if necessary. This means both parties 
are actually eyo gine systems that function at 
both. levels. 3°: and (network and transport 
layers) . The result of this work should create 
"yvirtual-connections" between two interconnected 
devices within the amateur network. This virtual- 
connection exists between the involved devices at 
the interface between the Transport Layer of the 
ISO reference model and whatever layer resides 
above it (such as a Session Layer). Since some 
may object to the term "virtual connection", I 
will instead use the term "logical network 
connection". 


Unfortunately, the word "network" has come to 
mean many different things. It can mean the 
general concept of a large group of nodes 
interconnected so that data can flow back and 
forth between any nodes within the group. This 
type of network can be geographically small (as in 
Local-Area-Network, or LAN)or large (such as the 
Telenet Network). This size grouping can add to 
the confusion when discussing networks. 


The term "network" can also mean the specific 
"Network Layer') or Level 3 of the ISO reference 
model. The network layer is sometimes considered 
two sub-layers, which can also be confusing. 


Throughout this paper, I will use the term 
"amateur network" when discussing the overall 
network concept. I will use the term "transport 
entity" when describing the interface between the 
upper ISO layers and the amateur network access 
point. When discussing a single cluster of 
potentially interconnected stations (such as a 
group of VHF packet stations within communications 
range), will use either the term "intranet" 
(thanks Paul!), or subnetwork, as the ISO calls 
it. The term "internet" (note lower case) will be 
used to describe the potential interconnection of 
individual intranetworks to form an amateur 
network. This is different from Internet, which 
is a specific internetworking protocol. 
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Services Renderred By The Amateur Network 


In the most basic terms, the amateur network 
should provide a means of transferring data from 
one amateur to another amateur. Ideally, both 
data integrity and transfer speed are important to 
all amateurs, but integrity and/or speed may be 
compromised in individual situations. The amateur 
network should be flexible enough to handle such 
ae requests as reduced integrity to increase 
throughput (speed) for applications such as 
packetized voice. The other end of the pendulum 
is equally important. If an amateur wants to send 
a machine language program across the amateur 
network, speed may be sacrificed in order to 
insure absolute data integrity. 


Since we amateurs live in the real world, and 
amateur radio is our hobby (it doesn't feel like 
it sometimes though), it is important to realize 
that whatever we do is on a small budget, and will 
likely suffer some disaster eventually. The 
amateur network should be designed with this in 
mind, and should be resiliant enough to cope with 
parts Of” 1G gotug down from time to time. 

henever possible, the amateur network should 
recover from difficulties without the users of the 
amateur network knowing something happened. 


If a user of the amateur network knows what 
path through the amateur network is used to 
establish a network interconnection to the amateur 
he/she wishes to communicate, the amateur network 
should attempt the network interconnection in that 
manner. If, on the other hand, tha amateur 
doesn't know the path to the other amateur (or 
even the destination transport entity where the 
other station exists), the amateur network ideally 
should provide some type of directory to aid in 
establishing the network interconnection. 
Obviously, this directory is a frill that won't be 
around for a while, but some method of using it 
should be provided. 


Sometimes it may be advantageous to provide 
some method of allowing the amateur network (or 
the other amateur's station) to directly read the 
status of, or control some parameters of an 
amateur's packet system. This may allow the 
amateur network to optimize level 2, 3, and 4 
timers, control viewing of passwords, etc. TAzs 
is sometimes referred to as an alternate control 
path to the amateur's packet system. 


The amateur network should also allow some 
method of network management by requesting the 
status of the amateur ntework, along with 
controlling certain functions of the amateur 
network. This should be done in various levels of 
control, along with having geographical boundries. 
Traditionally, amateurs prefer to operate ina 
non-autocratic enviroment, so a single amateur 
network: Control « orou is probably beyond 
possibility. A hierarchical system of control 
would be called for, allowing some amateurs to 
manage their local intranet, while others would 
manage a larger part of the amateur network. 


Cutting Up The Amateur Network Pie 


This amateur network is not going to blossom 
overnite. It will probably take much longer to 
develop than the level 2 standard did. Part of 
this is due to the added Se eae? Wie having 
multiply-interconnected devices that are so 
interdependant on each other. In order to speed 
up amateur network development, along with 
conforming to the ISO reference model, the amateur 
network sghould be broken up into several parts, 


each of which is responsible for a portion of 
amateur network operation. 


Transport Layer Services and Responsibilities 


. The Transport Layer (OSI Level 4) 
provides a metho of transferrim data 
transparently through the amateur network Tetween 
Session Layer entities such that the session- 
entities don't need to be concerned about 
assuring reliability or speed of data transfer 
through the amateur network. 


The Transport Layer does this by using 
an end-to-end protocol between the Transport 
devices at each end of a network interconnection. 
This protocol is responsible for establishing a 
network interconnection between two amateurs; 
maintaining data integrity, proper data 
sequencing, end-to-end flow control, and end-to- 
end error recovery during data transfer between 
the amateurs; and the release of the network 
interconnection when it is no longer needed. It 
should be noted that some of these functions may 
be altered/removed if requested. 


The Transport Layer is relieved of 
routing, relaying, and non-end-to-end flow control 
decisions by the network layer operating 
underneath it. 


The complexity of the Transport Layer is 
very dependant on the type of network operating 
underneath it. Some network protocols require a 
ns i Transport protocol to correct for potential 
problems, while other network protocols require 
almost no transport protocol. 


Network Layer Services and Responsibilities 


The ISO defines two portions of the 
Network Layer. Subnetworks are of one or more 
intermediate systems which provide relaying of 
data through which end-systems may estab Fish 
network-connections. A Network is considered the 
interconnection of these subnetworks to provide a 
communications path between Network end-points. 


The Network Layer (Level 3) is 
responsible for establishing a data path between 
two Transport Layer entities wishing to 
communicate through the amateur network. The 
Network Layer should provide this service to the 
transport layer in such a way as to make invisible 
how the network routed the data. This includes 
how many hops or relays it took, how many 
subnetworks it went through, and how many data 
links were used. As such, the service provided at 
each end of a network-connection should be the 
same, even if dissimiliar subnetworks are used 
somewhere between the two end-points. 


The quality of service provided is 
negotiated between the transport-entities and the 
network-entities at the time of network-connection 
establishment. If a quality of service is ae 
to, that quality of service shall remain in effect 
throughout the lifetime of a network-connection. 


The Network provides’ the 


following functions: 


Layer 


a) routing and relaying; 
b network-connections; 
c network-connection multiplexing 
d segmenting and blocking; 
e error detection and recovery; 
f sequencing; 
local flow control; 
F expedited data transfer; 
1 service selection; and 
j Network Layer management. 

The Network Layer data is transferred 
between individual network-entities through the 
use of Level 2 connections. In the amateur 
network, this usually means AX.25 HDLC connections 
between network nodes or entities. Level 2 AX.25 
is responsible for providing reliable node-to-node 
data paths between the network nodes. 

An important eden is that the qualit 
of service provided by the overall amateur networ 
is only as good as the weakest portion of the 
path through the network. 
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Proposed Datagram Network Standard 


The es: the 


§ slat 


ram network crowd is proposin 
use of the DARPA TCP/IP or UDP/IP standar 
puree the amateur network. The Internet (IP) 
protocol would be used at the network layer, and 
either the User Datagram Protocol (UDP) for use in 
unsophisticated transport enviroments, or the 
Transmission Control Protocol (TCP) for more 
reliable transport service. 


Proposed Virtual-Circuit Standard 


Most of the work being done in the virtual- 
Circuit area is being based on CCITT standards. 
One recommendation being proposed is as follows: 


Use CCITT X.25 Level 3 protocols for the 
connections between amateur network users and 
the amateur network entry point. 


Use “the COLT x. 75: devel3 protocol Lor che 
connections between devices within the 
amateur network. 


Use the CCITT X.224 Level4 protocol for the 
Transport connections (if necessary) between 
the two end-points of the amateur network. 


Head-To-Head Comarisons Of Virtual Circuits 
nd Datagram Type Network Operation 


As will soon become apparent, both the 
virtual-circuit and datagram network concepts have 
good points and bad points. It will be up to the 
amateur community and network designers to decide 
how these will be used in differing operating 
enviroments. 


Both of the amateur network concepts will 
create a logical network connection between the 
two end-points of the amateur network wishing to 
communicate. Both will have the capability of 
providin either reliable data transfer, or 
reduced reliability in favor of increased speed of 
data transfer. 


Design Philosophy 


Even though both network designs provide 
the end users the same service (potentially error- 
free data transmission rom source to 
destination), the way the two systems accomplish 
this goal is quite different. 


The datagram type network design works 
much like the way mail 1s delivered by the post 
office. Each letter (packet) has all the 
information necessary for that letter to be 
delivered independently of any other letter before 
or after it. Each datagram packet has both the 
source and destination addresses in a header 
prepended to the user data, along with some 
control information. This packet is then shot out 
into the air independently of how other packets 
for the same source were sent. It is up to the 
Transport Layer to make sure the packets do get 
from Source to.the destination in the: proper 
sequence and without corruption. This means that 
in a datagram network, the Transport Layer is 
relied on heavily to correct for Network Layer 
problems. 


The virtual-circuit type network 
operates more like the telephone system. When a 
telephone user wishes to talk to another telephone 
user, the first user establishes what looks like a 
direct wire circuit between the two users by 
dialing the destination users number. Once the 
call is established, every word (packet) flows 
from the source to the destination over the same 
Clrourt. Since the same circuits are used 
throughout the connection, it is not necessary to 
have an overseeing device make sure the wires 
don't move or change during the connection (yes, I 
realize there is pleas ere and line switching 
going on these days, ut lets not confuse the 
issue). When the users are done, one hangs up, 
and that triggers the tearing down of the circuit, 
making the wire connections available to others. 


It is now time to discuss some of the 
trade-offs between the two types of systems. 


Packet Header Overhead 


There is a large discrepency in the 
amount of header type overhead that the two 
network designs require. This may or may mot be 
important, but should be considered. 


In the datagram network, a minimum of 20 
bytes of overhead iS reguired by the Internet 
Protocol, with an additional amount required if 
options are to be selected. The Transport Layer 
protocol (TCP) requires an eee ronal 20 bytes 
minimum, again more is required if options are 
selected. Keep im mind that this 40 bytes minimum 
is required in EVERY SINGLE data packet sent. 


The virtual circuit network proposed 
relies on the fact that all the addressing 
information is loaded up in the connection 
establishment process. This can be up to 256 
bytes of data in the first connection request 
packet (assuming the Transport Layer connection 
request 1S in the fast-select portion of the 
network connection request). Once the connection 
is made, and as long as no major errors occur, 
the overhead drops drastically to three bytes for 
the Network Layer header and three to nine bytes 
ee ee Layer header overhead per data 
packet. 


EC. Hooks: Jake tne. Virtual: Circuit 
network design wins this one hands down. 


Packet Resequencing 


In datagram type networks, it is 
possible for packets sent after others to arrive 
at the destination before the earlier sent ones. 
This is similar to when two people correspond 
every day through the mail, sometimes a letter 
sent after another arrives before the earlier sent 
one. There MUST be some method of making sure 
that the out-of-sequence packets are re-sequenced 
before they can be delivered. While I have heard 
and read that some aioe ae consider this a 
"trivial" task, it does take up buffer space and 
processor time at the destination end-point. 


Since virtual-connection networks always 
use the same path for every packet (unless there 
has been a malfunction), the chances of this 
problem occuring are virtually eliminated, 
reducing processor and memory requirements. 


Once again, the virtual connection 
protocol seems to have the advantage. 


Routing Selection 


If the route through the amateur network 
is static (not altering for any reason other than 
network device failure), it can be argued that 
both iS es of network designs work equally well. 
The selection of routes for packets is in itself 
another argument for another time. It can also be 
argued that in a fully static network, the virtual 
connection may have a slight advantage, since the 
address overhead is not required if no decisions 
are to be made based on these addresses. 


If dynamic routing is allowed (where 
changes in the route of packets from source to 
destination can occur for a variety of reasons), 
the datagram type network has a distinct 
advantage. Since each datagram contains both 
address, routing decisions can easily be made, in 
worst case on a packet-by-packet basis. Since the 
virtual connection reduces its overhead by sending 
the addresses only during the connection 
establishment process and uses "logical channel 
numbers" from then on, it cannot easily alter the 
path of packets. Keep in mind that dynamic 
routing may add more problems than it corrects. 
Network oscillation, delays due to routing 
decision time, and sequence destruction are but a 
few of the problems associated with dynamic 
routing. 


Congestion Bypassing 


Avoiding routes that have become 
congested is only viable when some form of dynamic 
packet routing is employed. Since virtual 
connections do not lend themselves to dynamic 
routing of any kind, the capability of bypassing 
areas of congestion is a definate advantage of the 
datagram form of network. The only method of 


reducing congestion problems in virtual connection 
networks is to provide some sort of look-ahead 
routine to make sure that congestion is cut-off 
before it becomes a problem. Admitedly, this is a 
poor form of ete with this situation. The 
datagram becomes the big winner here. 


Tolerance to Switch Failure 


There are two issues to be concerned 
with in talking about packet switch failures. The 
first is what happens to the rest of the network 
when a switch fails, and the other issue is how 
does the switch itself recover from a failure 
(even a temporary one such as a power glitch). It 
appears that the datagram network is more 
resiliant in both these issues. If a packet 
switch fails in a virtual connection network, all 
connections through that switch must be torn down 
and re-established using another path (if 
available). The datagram network may have to do a 
Similar process if it is totally static routed, 
but if some form of dynamic routing is used, 
recovery is made much easier by just re-routing 
the data around the failed switch. 


The other issue is that of switch 
pease When a packet switch has recovered 
from a failure in datagram network, it just has to 
rebuild its routing table and inform the network 
it is back in operation. The virtual connection 
Switch must do this plus re-initialize all the 
connections passing through it. An additional 
problem is that some virtual connections may not 
realize that the switch has failed, causing 
additional hardship for the switch. 


It appears that the datagram network is 
ahead on this one also. Measures such as battery 
backup and uninterruptable supplies can help to 
reduce this, but again this is a kludge. 


Reliabilitv/Speed Tradeoffs 


Much has been made of this by the 
datagram group. It appears that even though both 
networks can be made to allow for reduced 
reliability in order to improve speed when the 
reduced ee 1sn't. a. concern -(such as 
packetized voice), the datagram network won't ty 
to force the reliability issue like the virtua 
connection network would. It is_up to the reader 
to decide if this is a real or imaginary 
advantage. It appears to be much easier to make a 
solid pipe (virtual connection) leaky by Ponty 
holes into it than to try to plug up the holes o 
a leaky pipe (datagram). At this point in time, I 
think this is almost a non-issue. 


Roving Station Situation 


It isn't much of a problem at the 
moment, but some thought should be given to the 
concept of a mobile packet station, either in an 
auto or an airplane for example. First thoughts 
seem to indicate that datagrams have an advantage 
in this situation. This 1s NOT so. Since both 
network designs age on providing a_ logical 
connection through the amateur network from a 
source end-point to a destination end-point, if 
one of these end-points was to change, both types 
of networks would have to re-establish the 
connection to the new end-point. It may be argued 
that datagrams may be easier to do this, since a 
whole connection doesn't have to be torn down and 
a new one errected. Since the Transport Layer 
devices must be changed anyway, the form of 
network re-establishment is not a major issue. 
Both forms of networks could employ similar 
methods of causing this reconnection to happen. 


Alternate Data Path 


Sometimes it is advantageous for either 
the network or the remote end user might want to 
control some parameter(s) of the user's terminal 
or computer. The CCITT has provided for this by 
allowing a method of establishing an alternate 
path (kind of an in-band method of out-of-band 
Signalling). This mechanism involves the use of 
the Qualifier, or Q-bit. The Q-bit is frequently 
used to provide the oe decir | to a host to 
control a user's PAD parameters (such as to turn 
off echo when entering passwords). As far as I 
know, there is no easy form to do this in the 
datagram network, unless options are defined to do 
ENLS: 
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Local Subnetwork Use 


One of the Clear advantages of the 
virtual connection networks is that it does follow 
the ISO reference model as far as subnetworks vs 
networks. The datagram network is good for what 
it is intended, an INTERNET protocol. Even the 
name implies that it hooks up networks and 
subnetworks to each other. IT IS NOT MEANT TO BE 
A SUBNETWORK PROTOCOL. What are we supposed to 
use within local subnetworks in the datagram 
network design??? TCP/IP works to interconnect 
subentworks, not act as the subnetwork protocol 
itself. Are we supposed to use just link layer 
prorocons when communicating need & THIS IS 

OTTALY WRONG! I cannot emphasize this enough. 
TCP/IP on a subnetwork level makes absolutely no 
sense. It takes up too much overhead, processing 
speed, channel overhead, and memory requirements. 
Much grumbling was heard at first about the 
overhead of the address field of level 2 AX.25. 
Imagime if every packet must have an additional 
40+ bytes of overhead to accomplish the same task. 
Some form of subnetwork protocol should be 
implemented, but TCP/IP is not it. Link 
Soe tone such as what we use today also are a 
mistake. 


A layered approach such as_ the 
virtual connection network design makes more 
sense. For the local subnetwork connections X.25 
seems to fit real nice. It is a small robust 
protocol whose major defects don't affect 
performance at a local level. Since it is 
connection oriented similar to the presently 
implemented level 2 AX.25 protocol, plenty of the 
work has already been done. 


The internetwork protocol of a virtual 
connection network would most likely be based on 
X.75, which its. a modified version.of X.25. Some 
additional work would be needed to make a 
complete network ae. but this would be fairl 
simple to accomplis Since X.75 is also virtua 
connection, and itis a version of X.25, the two 
can be mapped together quite nicely. 


The Transport Layer (if even required) 
is based on the CCITTX.224 standard (see another 
paper in these proceedings). X.224 is a multi- 
class protocol, and even the most basic class 
(class 0) handles the major hole in X.25/X.75 
network operation (that of re-establishing a 
connection after a switch failure). A more 
advanced class also provides for a checksum to 
eliminate the possibility of a switch with a 
memory malfunction corrupting an otherwise 
accurately transferred packet. 


Each of these protocols loads the major 
overhead burden into the connection establishment 
rocess, and then operates on a very small header 
udget. One more point, either the X.25 or the 
X.75 protocols would be used not both. MThis is 
to say that if a packet is originated in an X.25 
subnetwork and then transferred across the amateur 
network using X.75, both headers are not required, 
just the one being used at that particular network 
connection. 


Flow Controls 


Flow control throughout the network is 
handled DP enec ete by the two network designs. 
The datagram network normally does not provide any 
flow control at the Network Layer. Instead it 
relies on the Transport Layer for end-to-end flow 
control, and the Link Layer for everything else. 
Unfortunalely, if the Link Layer is relied on, 
when the Link 18s flow controlled, not just the one 
network connection flow is stopped, but ALL LEVEL 
2 data for ALL level 2 connections are stopped. 
Sometimes this is alright, but at other times this 
can be a big problem. There is no way around this 
problem. 


In a virtual connection network, each 
individual network connection can be flow 
controlled mca lieet of any other connection, 
independent of Level 2, independent of the 
See ferns Layer. Some argue that this 
multiplicity of possible controlling devices adds 
putece processing overhead and can lead to 
buffer problems stacking up and rippling through 
the network. I would point out that this most 
likely wouldn't happe Since. there a finite 
number of packets allowable in a network (in 
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either network design), due to Transport Layer 
sequence numbering constraints, in addition to 
Level 2 sequence numbering constraints. 


Circular File Philosophy 


One of the comments I hear from time to 
time is that a datagram network is easier to 
implement, because of the capability of just 
tossing out a packet if it cannot be handled'for 
any reason, and wait for a better time, or wait. tq 
see if the packet shows up again. I don't feel 
that the circular file is the place for my packets 
(Some may disagree). I would prefer the situation 
that if a packet shows up, the network tries its 
best to ae that packet through, and only if there 
is no other recourse (such as buffer limitations 
suddenly showing up) should the packet be thrown 
out or ignored. The cetartam approach seems to 
rely on this "tossing the offending packet" 
instead of trying to correct the situation that 
caused the offending packet in the first place. I 
repeat, my packets belong in a better place than 
the trash heap. 


Hardware/Software Considerations 


An important consideration is what kind 
of hardware and software will be needed to run the 
two protocols. The biggest single requirement in 
both types of networks is oing to be the 
requirement for lots and lots of RAM for buffers. 
The datagram type networks may need more buffers 
to be available at the end-points, while the need 
for more buffers in the virtual connection network 
may in the packet switches. It really depends on 
how the software is written as to how much 
buffering is required. 


Another hardware/software consideration 
is that of processing requirements. This can be 
broken down into the individual devices that make 
uP the network, The majority of the devices in 
the network will most likely be the packet switch. 
The datagram people claim that a datagram switch 
is easy to implement. Depending on the type of 
routing used, this may or may not be the case. If 
some form of dynamic routing is implemented, the 
packet switch suddenly becomes a much larger 
device requiring a lot more processor power to 
figure'out the route the packet should take to 
reach its destination. Dynamic routing of some 
sort will probably be implemented in the datagram 
type network, since most of the advantages of the 
datagram network can only be taken advantage of in 
a dynamic routing enviroment. 


A similar form of trade-off can be made 
in the packet switches of a virtual connection 
network, in a slightly different form. The first 
form is similar to the datagram approach. Full 
virtual connections are not maintained between 
every packet switch, but rather cross-connection 
tables are maintained at each switch (similar to 
the veer panel of an old phone excmrede) .This 
would allow very sea aig software to be implemented 
at the switches at first. The trade-off is that 
flow control can only be implemented at the 
Transport Layer or Link Layer ike the datagram 
network) . If each packet switch implements a full 
X.75 network connection to each neighbor switch 
processing overhead is increased, but the overall 
network becomes inherently more reliable. 


: The other device that must be considered 
is that of the network end-points. Here there is 
no question. Because of the need for a 
sophisticated Transport Layer protocol over ,a 
datagram Network Layer, the datagram network will 
require a substant ally larger device with much 
more processing overhead. Distributed processing 
(one micro for each layer) may be an absolute 
requirement for datagrams, while an option for 
virtual connections. 


An Ounce of Prevention... 


Most amateur network users will always 
require that the network transfer data RELIABLY, 
The two forms of network designs place this 
eee in different places within ae 
network. he datagram loads ALL this 
responsibility at the end-points of the network in 
the Transport Layer. Thedatagram Network Layer 
takes no responsibility whatsoever for maintaining 


data integrity. 


The virtual connection network places 
this res eae | in small portions throughout 
the entire network, with the last margain of 
safety at the end-points in the Transport Layer. 
This distribute Pace el Sehute metearerih scheme adds 
overhead throughout the network, but allows 
problems to be corrected along the way, rather 
than having eae Aree look fine until it reaches 
the end-point, and only then finding out an error 
occured early in the network. 


"What The Big Boys Use" 


An issue that is sometimes raised is 
that of who is using what form of network. The 
research community seems to have fully adopted the 
TCP/IP datagram network concept, as provided by 
ARPANET. This is fully understandable, since they 
can quite often easily obtain the processing power 
necessary to implement TCP/IP. Also, since most 
of the research centers these days interract with 
the defense department who owns the ARPA network, 
there is some political pressure to go that route. 


In the real world, the bottom line is 
the buck. The networks that are there not for 
research, but rather to provide the service of a 
data network (such as GTE Telenet) must look at 
how to provide a data network in the most cost- 
effective form, otherwise the competition will 


take their customers... It -18-interesting to note 
that the commercial networks use virtual 
connection protocols for their operation. In 


fact, Telenet was originally a datagram type 
network, but spent several million dollars to 
convert to a virtual connection network because 
they found out that the datagram network just 
wasn't cost effective. Some datagram peCr sc 
comment that the commercial data networks use 
virtual connection protocols because this shifts 
political network boundries out of the hands of 
the user and into the hands of the network. This 
seems to be based on articles in some of the 
computer journals around 1976. A lot has happened 
since then, including Telenet switching from 
datagrams to virtual connections. It is 
interesting to note just how many assumptions were 
made back then that are totally wrong today. Once 
again, the commercial networks use one yardstick 
for measuring their network, the biggest bang for 
the buck. No politics, because there is no room 
for polities. If they relied on political 
considerations, one of their competitors might 
not, and there goes the customers. It seems that 


the only people that can use political games are 
those that don't necessarily look at the bottom 
line, but can instead justify some additional 
costs Aor the sake of research. Does someone come 
to mind? 


Conclusion 


The major question I have for those 
implementing TCP/IP is what they are going to 
implement for the subnetwork (or intranet, or 
local network, or metropolitan network)? What are 
we ara oa to use when packeting on a local basis 
to other hams in our area? Since a lot of our 
communications will always be within a 
metropolitan area, this issue MUST be addressed. 
Are we all supposed to support TCP/IP or UDP/IP? 
That won't work. You just can't shoe-horn all that 
on a TAPR board. Are we supposed to just continue 
to use Link Layer procedures when packetin 
locally? That isn't the right answer either. 
believe that an AX.25 Level 3 machine could be 
shoe-horned into a TAPR board if one really tried. 


As it appears from the above, I am going to 
continue the development of virtual connection 
network protocols. I do believe there will be a 
use for both network designs, and the best way to 
chose the correct one for the majority of the 
amateur network is to have both operate in a head- 
to-head competition. I do feel strongly that 
there is going to be a local subnetwork 
(intranetwork) protocol developed for local 
metropolitan users. This protocol does not have 
to be the same as the internetworking protocol 
used. In fact, I think there will most likely be 
some gateway operation to interconnect virtual 
connection networks with datagram networks. One 
point about this, I have heard some amateurs argue 
that if a part of a network is datagram then ALL 
of the network MUST be datagram (or vice versa>. 
This is not true!! All that must be done is that 
the gateway between the two types of networks must 
perform protocol conversions at both levels three 
and four. Since the two levels are so intertwined 
SS apie with datagrams) this task must be 
accomplished. If it is done correctly, it should 
appear as if nothing out of the ordinary is 
happening. 


My last comment is that given a piece of 
information that can be transferred using either 
method, which would you prefer and trust, the post 
office or the telephone system? 
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Overview 


In order to assure absolute data iu eeota ly 
through the amateur network, some form o 

transport layer protocol should be employed 
between the entry and exit points of the network. 
In datagram service, this transport comes in two 
basic forms, the Transmission Control Procedure 
(the TCP in TCP/IP) and the User Datagram 
Prococol, oO) UDF: The UDP is a very small 
transport protocol, and as such does not provide 
absolute data integrity under all conditions. The 
TCP is a much more robust protocol, and as such is 
capable of assuring absolute data integrity 
through the network, with a much higher overhead. 


The Virtual Circuit amateur network concept 
using the CCITT standards (X.25/X.75) has 
generally relied on the use of the delivery 
confirmation, or D-bit procedures to maintain data 
integrity. Not only is this potentially a 
violation of the ISO seven-layer model, but is 
also inadequate. If a virtual circuit connection 
is lost due to an intermediate packet switch 
malfunction, the D-bit procedures alone may not 

rovide an accurate indication of what data was 
ost due to the malfunction. In addition, use of 
the D-bit rovides no mechanism of detecting 
errors within the packet switches (such as memory 
errors) that might corrupt otherwise good data 
flowing through the amateur network. 


This paper pepe the use..of another CCITT 
xX series protocol to correct: for these potential 
deficiencies. This is a new recommendation, 
called X.224, and it describes a multi-class 
Transpoirt Layer protocol that can be used on top 
of the X.25/X.75 Level 3 protocols. I will not 
give a detailed protocol specification here, but 
rather describe the different classes of the 
protocol and some of how they function. 


Transport Layer Responsibilities 


The basic function of the Transport Layer is 
to make sure that data traveling from the source 
end-point of a network to the destination end- 
point of the network does so in the proper order 
and without data corruption (if necessary). The 
Transport Layer relies on the Network Layer for 
providing a method of getting the data through the 
network from the source end-pointt to the 
destination end-point. Once the Transport Layer 
entity is sure that the data leaving it matches 
the data entering its peer Transport Layer entity, 
it will pass the data up to the next layer for 
further processing if required. The Transport 
Layer should have at its disposal some method of 
detecting errors, informing its Transport peer of 
these errors if necessary, and possibly correcting 
some forms of errors commonly encountered. 


Errors Encountered By The Transport Layer 


Before the X.224 Transport Layer 
recommendation is discussed, it might be helpful 
to describe some of the errors and situations a 
Transport Layer might have to deal with. Among 
these situations are: 


Data Loss. 

Data Corruption. 

Data Duplication. 

Data Misordering. 

Data Misdelivery. 

Network flow-controlled. 

Upper layer flow-controlled. 

Network Concatenation and Separation. 
Segmenting and Reassembly. 


HOODAAVAWY 


J. Splitting and Recombining. 
K. Multiplexing and Demultiplexing. 


Data Loss 


Loss of data can occur for a number of 
reasons in a network. If an intermediate packet 
Switch goes down while holding data it 
acknowledged receiving but before sending to the 
next switch is one example. Total network failure 
is example of absolute data loss. These type of 
failures should be detected and corrected. This 
may mean a request for the missing data should be 
sent, or possibly tearing down the malfunctioning 
connection through the network and informing the 
user of the network failure. 


Data Corruption 


Data corruption is when data passes 
through the network from the source end-point to 
the destination end-point, but something saad 
to it along the way to create errors in it. ile 
most of the time data passed through the amateur 
network will be passed from point-to-point using a 
reliable Link Layer protocol (such as AX.25), if 
an intermediate packet switch has a nen | 
malfunction, data passed through that switch wil 
be corrupted. Since the network corrupted the 
data, there should be some method of detecting and 
correcting this situation, if necessary. 


Data Duplication 


It is possible to have the same data 
delivered to the Transport Layer more than once. 
This happens most frequently when retransmissions 
due to Voss of acknowledgements occur. In 
datagram networks can happen a lot when some type 
of flooding mechanism is used to correct network 
deficiencies. There should be some sort of 
detection of duplicated data, which results in the 
duplications being thrown out. 


Data Misordering 


With some network desi ns, it 1s 
possible for a group of data send be 4ore another 
group to arrive at_the destination AFTER the 
second send group. This is common with datagram 
networks employing some sort of dynamic network 
routing scheme. ot only should this be detected, 
but some method of data re-ordering must be used 
to regain the original data order. 


Data Misdelivery 


Whenever the Transport Layer receives 
data from the Network Layer that it does not 
understand what to do with for reasons other than 
specified, it should have some method for acting 
upon the error. This can be as simple as ignoring 
the bad data, or as drastic as tearing down the 
Transport connection and notifying the user that 
the network has failed. This is kind of a catch- 
all for the "I'm so confused" feeling. 


Network Flow-Controlled 


While not an error, if not properly 
handled network flow control could cause the 
Transport Layer to become congested when the upper 
layer(s) keeps sending data that the Transport 
Layer cannot send over the network. Some method 
of flow-controlling the ppee layer(s) should be 
employed to prevent data loss due to this 
potential situation. 
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Upper Layer Flow Controlled 


This is also not an error, but rather a 
Situation that could cause errors. If the upper 
lavyer(s) cannot accent more data from the 
network-through the Transport Layer, that upper 
layer(s) may try to stop further data from 
reaching it from the Transport Layer. If the 
Transport Layer is not capable of reacting 
properly, data may become lost between the layers. 


Network Concatenation and Separation 


Some networks allow the Network Layer 
protocol to concatenate more than one Transport 
Layer data unit into a single Network Layer data 
unit at the source end-point, and then separate 
the Transport Layer data units at the destination 
end-point. This may cause some problems at the 
Network/Transport Layer interface, which must be 
handled by the Transport Layer. 


Segmentation and Reassembly 


If the Transport Layer receives data 
from the pees layer(s) in a group or size that it 
cannot handle in a single Transport Layer data 
unit, it should break the data into multiple 
smaller Transport data units for sending through 
the network. The destination Transport Layer end- 
point should be capable of reassembling these 
samller data units into their original form before 
passing the data to the upper layer protocol(s). 
Some method of indicating this segmenting must be 
employed, along with some numbering scheme to make 
sure the data is reassembled properly at the 
destination end-point. 


Splitting and Recombining 


Occasionally Transport Layer protocols 
may use more than one network connection to 
support the same Transport Layer connection. If 
this happens, some of the above mentioned data 
errors may occur, especially data misordering. 
Special procedures may be required to support this 
function. 


Multiplexing and Demultiplexing 


This is when a single Network Layer 
connection is shared multiple Transport Layer 
connections. This will happen frequently, since 
it will result in reduced Network Layer overhead. 
Some method of assuring proper demultiplexing 
should be employed, otherwise the wrong user may 
get someone elses data. 


There are more potential errors that can 
anes into. the network system. The above 
highlights(?) some of the more common problem 
areas. 


CCITT X.224 Recommendation 


The CCITT has written Recommendation X.224 to 
serve as a Transport Layer Specification for Open 
Systems Interconnection networks. It is designed 
to be flexible enough to be used with a variety of 
Network Layers operating underneath it, while 
requiring a minimum amount of overhead. 


Like most Transport Layer protocols, X.224 is 
designed to establish a "virtual connection" 
between two Transport Layer peers. In order not 
to ruffle the feathers of the datagramies, I will 
use the term "logical connection" in place of 
"virtual connection" throughout the rest of this 
paper. 


One of the peers in this logical connection 
is called the source. end-point, ‘andthe -ocher is 
called the destination end-point. This is not 
meant to imply that data flows only in one 
direction, but rather that when an upper layer 
protocol sends a Transport Layer some data, as far 
as that data is concerned, it is at the source 
end-point of the Transport Layer connection. the 
source Transport Layer end-point then adds any 
overhead to the data that it may require for 
proper Transport Layer operation, and sends the 
resulting data to the Network Layer below it for 
transferring the data across the network to the 
destination Transport end-point. 


The destination Transport Layer end-point 
then receives the data from its Network Layer, 
strips off and acts upon the overhead added by the 
source Transport end-point? and if everything is 
fine,. asses the resulting data to its upper 
layer(s) for further processing. 


As long as it is required to transfer data 
between network users, and no major errors occur, 
the logical connection between the two Transport 
Layer peers is maintained. Some errors can be 
recovered from using X.224 procedures, while 
others require tearing down, and re-establishin 
the logical connection, if it is still wante 
after the error. 


In order to provide one recommendation that 
is robust enough to handle different qualities of 
service peewee by different networks, X.224 uses 
five different classes of protocols. This has the 
advantage of not requiring unnecessary overhead 
when using network protocols that provide a high 
degree of reliability, while allowing the overhead 
to grow to support network protocols that less 
guality of service. 


CCITT X.224 Classes 
The five classes of X.224 are: 


Class 0. Simple Class. 

Class 1. Basic Error Recovery Class. 

Class 2. Multiplexing Class. 

Class 3. Error Recovery and Multiplexing. 
Class 4. Error Detection and Recovery clase: 


The class of Transport Layer protocol 
used is inversely proportional to the quality of 
service provided te the Network Layer. If the 
network and the Network Layer protocol provides a 
high quality of service, then a simple Transport 
Layer protocol can be used. When the network 
service quality is poorer., a more sophisticated 
Transport Layer protocol might be required. There 
are three classifications of network quality 
defined in X.224: 


Type A. Network operation with acceptable 
residual error rate (errors not 
as by disconnect or reset) 
and an acceptable rate of signalled 


errors. 

Type B. Network Operates with acceptable 
residua error rate, but 
unacceptable rate of signalled 
errors. 


Type C. Network operation with unacceptable 
residual error rate. 


Class-. 0; 


Class 0 provides the simplest type of 
Transport Layer connection. It is designed to be 
used with type A network connections. It provides 
the functions necessary for logical connection 
establishment, data transfer with segmenting, and 
error reporting. Flow control relies on network 
provided flow control, and disconnection based on 
network service disconnection. 


Class 1. 


. Glass 1. provides. a basic ‘transport 
connection with minimal overhead, and is usuall 


used with type B networks. The main purpose o 
class 1 is to recover from a network disconnect or 
reset. This is the basic class recommended for 


use in the amateur network over AX.25/AX.75 
Network Layer protocols when absolute data 
integrity is not required. 


Class 1 provides transport connections 
with flow control based on network provided flow 
control, error recovery, expedited data transfer, 
disconnection, along with the ability to provide 
consecutive transport connections on a network 
connection. In addition to co Class 0 
functions, Class 1 also provides the ability to 
recover from Network failures without affectin 
the network user. This is the main advantage o 
Class 1, and corrects for a potential problem in 
AX.25/AX.75 network designs. 


4.37 


Class 2. 


Class: 2-415 Geer guce to be used with eave 
A networks. It provides a way to multip lex 
several transport connections onto a single 
network connection. Class 2 also allows the use 
of transport flow controls to help avoid 
congestion at Transport Layer connections end- 
points. No error detection or recovery is 
provided by class 2. 


Tf. the network connection -Fresets or 
disconnects, the transport connection is 
terminated, and the user is informed. 


Class 3. 


Class 3 provides the characteristics of 
class 2 with explicit flow control, plus the 
ability to recover from network disconnects or or 
resets from class 1. This is usually used with 
type B networks. 


Class 4. 


Class 4 is the most sophisticated 
Transport Layer protocol, and is designed for use 
with type C networks. In addition to providing 
Class 3 services, it also detects and recovers 
from errors which occur as a result of a low grade 
of service from the network. The kinds of errors 
detected include: 


A. Data Loss. 

B. Out-of-Sequence Data Delivery. 
6 Data Duplication. 

D Data corruption. 


Detection and recovery from errors is 
enhanced by the extended use of data sequence 
numbering, timeout procedures, anda simple 
checksum system. 


The class of protocol used can be negotiated 
at connection request time. If the preferred 
class is not available, an alternate may be 
selected, if appropriate. 


X.224 Headers 


Figure 1 shows the basic structure for the 
Transport Layer headers used in X.224. These 
headers are an integral number of octets long. 


octet 
] 


Figure 1. X.224 Transport Layer Header 


LI is the Length Indicator field. It 
indicates how long the Transport header is in 
binary (less the LI itself). The maximum value is 
204-octets- (LL1iL 1110). 


The fixed part contains frequently occuring 
parameters, including the coding of the Transport 
Protocol Data Unit (TPDU) type. The length of the 
fixed part is determined by the type of data unit, 
protocol. class, and formavt..an° use (normal or 
extended). The coding of the TPDU types are shown 
in Figure 2. 


| TPDU Nam LOL 2t3tat coding ! 
| em we Se ee i lah aa edd a a aca iat Sra a 
'CR! connect request Ix!x!xlx!x! 1110xxxx ! 
'CC! connect confirmation Ix!x!xlx!x! 1101xxxx ! 
'DR! disconnect request Ix!x!x!x!x! 10000000 
'DC! disconnect confirm.  Ixlx!x!x! 11000000 


l 
t 
! tx!Fflx!x! 00010000 
i 
l 


'DT! data Pele xt. L000 
'ED! expedited data 
'AK! data acknowledgement ! IClF!x!x! 0110zz2z 


! txtFix!x! 00100000 ! 
lo Ix! Ix! !§ QO1lOlzzzz ! 
Ixlx!tx!x!x! 01110000 


IRA! expedited data ack. 
'RJ! reject 
'ER! TPDU error 


{PL! Tranuspart Protocol TD ' Hi h F h ! 00000001 ' 
1 "~~ "+ 99000000 | 
already in use by other protocols ! 00110000 ! 
! not al Lwed in CCITT X.224 rat eee 
XXXX 


Figure 2. TPDU Coding and Class Usage 


Where: 
XXXX indicates initial credit allocation in 
oe is 2, 3, and 4. 0000 in classes 0, 
an 


2222 indicates initial credit allocation in 
classes 2, 3, and 41111 in class 1. 


F Not available when non explicit flow 
control option is selected. 


@ Not available when receipt confirmation 
option is selected. 


The variable part is used to indicated less 
frequently used parameters, if any are needed. 
The first octet of each arameter holds the 
parameter code, the second octet contains the 
aa value length indicator, and the rest 

olds the parameter value itself. An example of 
use of the variable part is the use of checksums 
for the class 4 protocol. 


The data field contains transparent user 
data, if any. Size restrictions depend on each 
TPDU! obey pes 


TPDU Header Structures 


Figure 3 gives an outline of the structures 
of the headers used. It is not meant to be a 
complete description, just a brief indication of 
TPDU header size. 


As mentioned above, the LI field is used to 
indicate how long (less the LI field itself) the 
Transport Layer header is. 


The second byte contains the TPDU type, and 
optionally a credit field. 


The DST-REF field is used to contain the 
address of the destination Transport end-point, 
and the SRC-REF holds the address of the source 
Transport end-point. 


Connection requests and Connection 
confirmation headers contain a single-octet field 
that hold the preferred class the requesting 
Transport device wants to use, along with two 
option bits (use/non-use of explicit flow control 
and normal/extended formats in classes 2, 3, or 4. 


Additional parameters may be requested in the 
variable part field, and are selected from among 
the following: 


Transport Data unit size. 

Version Number of Transport protocol. 
Security parameters. 

Checksum operation (class 4). 
Alternative protocol class(es). 
Acknowledge time adjustment. 
Throughput adjustment. 

Residual error rate. 

Priority of data. 

Transit delay. 
Reassignment/resynchronizationtime. 
Expidated data, additional options. 


FNQHTOyFo0e wt 


Lt “a Ot sSconnect TPDUs -sent; 2c should 
include a reason field which indicates why the 
disconnect was requested. 


Data TPDUs contain a field that contains a 
bit (called EOT) which indicates when a TPDU is 
the end of asequence of TPDUs. This field also 
contains the TPDU-NR, the TPDU send-sequence 
number. The TPDU-NR is set to zero in class 0, 
and may be any value in class 2 without explicit 
flow control. 


Acknowledgement TPDUs contain a field called 
YR-TU-NR. This field contains the sequence number 
of the next expected data TPDU. It is used to 
indicate the last correctly received data TPDU to 
the source Transport end-point. 


The last type of field used is the reject 
cause field in error TPDUs. As implied, it 
informs the source Transport end-point that the 
destination Transport end-point has rejected @ 
TPDU, and why. 
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OCTET Connection Request Header 7 
! 2 3 ! 4 ! 5 ! 


{1 : ! ! 6 6! 7 ! §8 P! P+] ! 
t LI. He .TCDT nm - - CLAS . 3 ' 
i 10110! ! 00000000 00000000 ! ! OPTIONS ! PART ! l 
OCTET Connection Confirm Header 

{i ! 2 ! 3 ! 4 ! 5 ! ! 7 tf 8 | P! p+i 


° e e cy e po ww J . 
11101! ! ! ! OPTIONS ! PART ! 


rigs Disconnect Request Header . 


2 ' 3 #{$ 4 ~ ! § t$ 6 ! JF $$: #8 £ BP! P+ ! 


11000 0000 ! ! ' f PART ! ' 
OCTET Disconnect Confirm Header 

!1 ! 2 | 3 ! 4 ! 5 ! 6 ! 7 P! 

Y Li ! DC ! D —— eS = ee Cee 

! £1100 0000 ! ! ! PART ! 

OCTET : 

! 1 Class 0 and 1 Data Hoods ...end ! 

Lr DT USEK DATA = 
! 1111 0000 and EOT t ! 


OCTET normal {former Class Dis, Oy ac 4 Data Header 
!1 ! 2 3 4 5 6 P! P+l . ..end ! 


| 11111 0000 | : and EOT PART ! t 


OCTET Extended Format Class 2, 3, and 4 Data Header 
! ! 2 { 3 ! 4 ! 5 6 7 819 


! ! P! P+] . ..end ' 
+ Lil 4 2 - - y VARIABLE 
! '1111 0000 ! ! and EOT ! PART t ! 


OCTET Normal Format Class 1, 2, 3, and 4 Bepee eee Data Header ‘ 
ae ee 3 | 5 | 6 +1 end ! 
= 1 = = T a ! 


LI T 

! 10001 0000 ! ! and EOT ! PART ! ! 
OCTET Extended Format Class 2, 3, and 4 Expedited Data Header é 
a 2 ae: ee 4 ! 5 6 7 8! 9 P! P+1 ...end ! 


! 10001 0000 ! ' and EOT PART ' 


OCTET Normal Format Class 1, 2, 3, 4 Data Ack Header . 
!1 ! 2 ! 3 ft 4 ae) !, 6 P! 


1 - 1 - - d iy 


LI 
! TOL I ! PART ! 


o— © 


OCTET EA enee? Former oe ae 25 » 4 Data Ack Header 
!1 ! 2 3 4 7 1 9 10 ! 


3 

6 Teh Pp 
1 I 0110 0000 I : ' ! PART 
OCTET Normal Format Class 1, 2, 3 
'.! 2 1 3 ! 4 


4 Expedited Data Ack Header . 
iF 5 1. 6 Pp! 


TTI = =TU= 1 r 
! 0010 0000 ! t ! PART ! 


OCTET Extended Format Class ge 32 me 4 Expedited Data Ack Header . 
1 2 "5 6 7 8 9 P! 


tt fa Bsr ‘Evry VRE 
! ! 0010 0000 ! ! PART 


fe Normal Format Class 1 and 3 Reject Header . 


OCTET lass 5 Ke ject ‘ 
!1 ! 2 ExtendédFormat. 5 6 7 Reject Header 10 ! 

! DST ! 4 REF YR = TU BNR 1 9 CDI TF 
! ! 0101 0000 ! ! ! ! 


ears 
al p | 3 #+¢ 4 ! Error Header . PI 

ER——1— DST REF? REJECT . 1VARTABLE 3 
{ 0111 0000 ! ! CAUSE ! PART ! 


Figure X.224 Transport Protocol Data Unit (TPDU) Header Formats 
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Procedures Available By Class 


Figure 4 shows the various procedures of 


X.224, and in which classes they are available. 
! | 
: Procedure ! Variant NNT tai3tat 
{Assignment to network cnct ! Get 
! TPDU data transfer Pxtxcloclcl x] 
! Segqmenting, reassembly Po ae Cb.ab a. 
!Concatenation, separation ! | Ixytxlxtx! 
! Connect. establishment ! Par ee ao ab 4 
! Connection refusal | ixtxbxtxtx! 
! Normal Release | AnmplicitIxl fl 1 4 
| | explicit ! Ixtx!x!x! 
! Error release | txt fx! Jos 
! Assoc. of TPDU with TCs ! Ix!x!lx!x!x! 
! Data TPDU numbering ! normal ! tx!m!m!m! 
! ! extended ! ! !olo!o! 
! Expedited data transfer !net normal ! !m!x!x!x! 
! inet explic.! wot Wt! 
! Reassignment after fail. Pel txts! 
| Retention until acknow- !Conf. rept.! role: fd 
| ledgement of TPDUs ! AK 1 Im! tx!x! 
| Resvnchronization ! Pog alo! 
! Multiplexing, de-muxing ! mee a> <><. 
! Explicit Flow Control ' with ay RE aoc 
! ! without !x!x!o! 
x! 


| use of tree 


Checksum 
jnon-use of Ixtxtx!x!o! 


! Frozen references beh td setxh 
! Retransmission on timeout | ne eae ee a 
! Resequencing ! Por wt 
| Inactivity Control ; PiYod ote tx 
! Treatment protocol errors! Ixtxtxt!x!x! 
| Splitting and Recombining! 1, sot ty 


X.224 Procedures 


Tt. 18 beyond the ‘scope: -of Ehis “paper, to 
describe the full operation procedures of the 
various X.224 classes. 
presented to show that there is an alternative 
Transport protocol to TCP that would work very 


The above information is 
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effectively on top of an X.251X.75 type Network 
ae ep protocol. 1 wild -continue: to. process .the 

24 document into a form that will be 
presentable to amateurs, along with making sure 
that it is 100% amateur compatible. 


The basic operational procedures of X.224 is 
designed to allow a logical connection to be 
established between a source Transport end-point 
and a destination Transport end-point using the 
connection request and connect confirm TPDUs, 
which may be passed along as part of the data 
field of an X.25/X.75 Ntework Layer fast-select 
connect. request. 


Once a connection has been established, data 
may flow in both directions, with optional flow 
controls, checksums, and sequence numbers. 
Optionally, expedited data can also be sent. Bad 
data can be rejected if necessary, and protocol 
errors can be detected and signalled. 
may be. terminated either vexplicitly,. or by 

nference when the network connection servicing 
the Transport Layer is torn down. 


When the connection is no longer needed, 


Conclusion 


I believe that X.224 is a viable Transport 
tok protocol to use over an X.25/X.75 network. 
provides the small extra amount of 
protection over the X.25/X.75 network layer to 
insure absolute data integrity when necessary at a 
very low amount of overhead. Since X.224 is 
Similar to AX.25 level 2 operation and X. 25/X.75 
network operation, an extensive software 
development campaign is not necessary to 
implement this protocol. Level 2 and level 3 
protocol machines could be modified to provide 
much of the basic core of the X.224 protocol. 


Interested users are encouraged to write the 
author for the latest in X.224 development, along 
with AX.25/AX.75 Network Layer development. It is 
also recommended to join AMRAD, as the AMRAD 
Newsletter contains fairly up-to- date information 


On packet radio development. 


FADCA GATOR LINK 1 PACKET RADIO LINKING NETWORK 


Howard Goldstein, 
681 Cardinal St. SE 
Palm Bay, Fl 32907 


BACEGROUND 


Oe A ED See OS ES a SE a 


The GATOR LINK 1 concept was devised 
in the summer of 1984 by a-_- group of 
members of the Florida Amateur Digital 
Communications Association (FADCA) as a 
method of linking packet radio digipeaters 
into a system that would provide wide area 
communicati ond without the problems 
involved in single frequency digipeating. 
It was recognized that while AX.25 Level 2 
provided a means of linking digipeaters, 
as packet radio activity grew, it would be 
more difficult to use this feature because 
of collisions. 


RF_ EQUIPMENT 

After a look at 23 cm as a possible 
band for linking, it was decided to use 
1.25 meters because of the availability of 
equipment . The basic radio for the high 
speed side of GATOR 1 will be the 
Hamtronics FM-5 220 mHz. transceiver. The 
FSK modification done by Steve Goode will 
be incorporated to permit 9600 baud 
operation, GATOR 1 nodes wi 11 communicate 
point to point with up to three other 
GATOR 1 nodes. For this reason, 
directional antennas will be _ used, On the 
two meter side of a GATOR 1 node will use 
the normal two meter FM transceiver, 


FREQUENCIES 


A frequency plan using 145.01, .03, 
07 and .09 will provide 150 mile co- 
protection of two meter 
in Florida. This will help 
relieve the common problem of digipeater 
to digipeater interference, All of the 
high speed 1.25 meter operation will be on 
2271.4 mHz. The Florida Repeater Counci 1 
haS coordinated 145.01, 221.4, 221.72 and 
271.78 mHz for 20 kHz bandwidth and 220.57 


O35, 
channel 
digipeaters 


mHz. for 100 Khz bandwidth state wide 
packet radio operation, FADCA has asked 
the FRC for additional coordination of 
145.03, .95, .07, and .0O9 mHz. for state 
wide use with FADCA to serve as_ the 
coordinating body for all packet radio 
frequencies in Florida, NO action has 


been taken by the FRC on this request yet. 


COMPBTER EQUIPMENT 


The brains of a GATOR 1 node will be 
the Xerox 820 computer with a FAD board, 
One af us (Goldstein) designed the FAD 


board, which uses a _ Zilog Z-8530A serial 


N2WX 
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Ted Huf, K4NTA 
1829 N.W. Pinetree Way 
Stuart, Fl 33494 


communications controller, This two port 
device will use one port for the 1200 baud 
two meter link and the other for the 9400 
baud on 1.25 meters. The FAD board which 
is available from TAPR was first described 
in the June 1984 issue of the Florida 
Amateur Digital Communications Association 
newsletter, the FADCA>BEACON. 


The modified Xerox 820 serves as a 
two meter digipeater for extending the 
range within a local area network, as well 
a5 a link into the GATOR’ 1 network from 
two meters and a relay station along the 
GATOR 1 network- Modifications to the g20 
include removal of the GP PIO, disk 
controller and video chips, The 
modification includes the useo f 2764 
eproms. A FADCA Bell 202 type modem 
designed by Jerry Rui mby, N4AJH will be 
used on the 1200 baud side. And because 
of oOUr commitment to provide emergency 
communication if needed, every effort will 
be made to provide GATOR 1 nodes with back 
up power. Figure 1 is a block diagram of 
a typical GATOR 1 node, 


PROTOCOL HISTORY 

The following is derived from_ the 
description of the proposed GATOR LINK 1 
protocol that was published in the June 


1984 issue of the FADCA>REACON, originally 
written by one of us (Goldstein), 


designed a system to 
these switches. that 
an AX.25 level 2 


One of us (Huf) 
assign addresses’ to 
nut only 1 ooks’ like 
address field, but also is easy for the 
end user to deduce without hard-to-find 
materials, Therefore, each GATOR 1 switch 
is identified by the area code (ala Fell) 
it serve5 ion, addition to the airport 
designator (ex. S13TPA, 404ATL). Whena 
switch hears a 1200 baud frame who’s next 
outstanding address sub field matches it's 


own, it assumes that it is meant for relay 
and attempts to route it to an adjacent 
switch that is virtually closer to the 
destination along the connection it 
maintains with up to 3 of these GATOR 1 
switches, 
HOW IT _WARKS 

The information field in frames 


received from a high speed connection are 
parsed for their ultimate destination and 
get sent either to a switch closer to the 
destination area, or are passed _ to the 


1200 baud transmit buffer if the local 
address matches the destination address. 


EXAMPLES 


Two examples of how an end user might 
set up a connection using the GATOR 1 


system: MIAMI FL TO JACKSONVILLE FL. the 
user specifies: CONNECT N4UF VIA SOSMIA 
9O4JAX. Assuming the SOSMIA switch hears 
me, it wi 11 take every one of my frames, 
set the H (has been repeated) bit on 
SOSMIA and insert it into ae virtual 
circuit with an adjacent switch that is 
nearer the #04 area code. Note that the 
routing is implicit, i.e. the path that 


implied by the 
and not by the 


the frames traverse is 
destination of each frame, 
USEr « 


ORLANDO TO WEST PALM BEACH: CONNECT 
WASHXZ VIA K4AHO SOSORL 3OSWPB WA4ARE-1. 
This example assumes that the AHO 
digipeater is needed in Orlando to reach 
the 30S0ORL switch, The same condition 
exists between WA4SHXZ and SOSWPB in this 
example. 


The software machine that is the 
GATOR 1 switch was designed to fit into 
the 1K or so bytes left in the 2716 EPROM 


pair, and to run concurrently with the 
regular 1200 baud (low speed) digipeater 
code on the Xerox 820 (See Fig. ifor 


The @& channel of the 8530 
is used for the high speed side and the B 
port for the existing low speed channel . 
In this fashion interrupt priority is 
given to data flowing on the A channel, as 
servicing here must be accomplished much 
faster because the data rate is higher, 


block diagram), 


RATOR 1. PROTOCOL 


The high speed links, i1.@. the 
connect i ons between adjacent GATOR 1 
switches, use a virtual connecti on 


protocol similar to AX.25 level 3, but 
simplified. Each GATOR 1 switch will 
strive to maintain a connection with its 


neighbors’ by polling the current 
connection state and, should the 
connection be _ down, sending GATOR 1 
connect frames to the appropriate switch, 
Once the connection&) have been 
established with adjacent switches, they 


may now exchange data. 


Frames passed between the switches 
are from 3 to 4096 octets long (excluding 
flag and CRC bytes). The shortest frames 
contain the source and destination CID 
{city ID) octets and a single command or 
Status octet. Longer frames contain these 
plus an information field, which may 
contain multiple sub fields, each 
containing a complete copy of the relayed 
AX.Z4 level 2 frame, 


CONCLUSION 

We realize that by proposing a 
linking facility that isn't "morally" 
consistent and doesn’ t even use the AX. 25 
Link-Layer it might seem we have rejected 
its use, This is not the case — in no way 
do we mean to discourage the proliferation 
of AX.25. $|Instead, the proposal simply 
reflects the current situation where there 
is no alternative for linking connections 
between different stations along anything 
but digipeat paths. The dilemma is in 
finding talented developers not of 
vaporware, but of software, and powerful 
and environmentally robust hardware that 
is inexpensive. If the latter situation 
was remedied, maybe some of the vaporware 
one hears about would congeal into 
something that works. Until then, the 
pragmatic aura of reality obscures all but 
that which exists, But here we find a 
very simple, talking alligator. It said 
something. ...Braaap???? 


FIGURE 2 
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FIGURE 1 


7iN /IN 
imag: ! 220 MHZ! 
+ 2M FM i : FSK H 
! XCEIVER } set ano RENARD !XCEIVER } 
e @--- --, E ' ' 
| oe eee a a ee Ree r] ' Bawa awe ee — a sae a as 1 
' 1: BATT + 3 : 
H +: CHARGER } H 
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H 202 ; H : FSK H 
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H } H 
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H FAD H ! 
; BOARD i H 
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TYPICAL GATOR 1 LINK STATION 


FIGURE 3 


‘FLAG: DEST CID:SRC CID:!CMD/STAT: INFO: CRC:FLAG: 
where: DEST CID, 
SRC CID are unique octets assigned 
to a switch as its address 
INFO only where the CMD specifies an info frame, 
formatted 1 i kes 


Se as menace nits Connected/Connected* 
Seg gs eae rae VV (S) 3--Mod 2 seq-defined only for I frames 


Offset Comments 
+0, +1 Length of following sub field (L) 
+70 ..L+1 Data in sub field 
{L+2,L+3 length of second sub field 
ennensand info, ad nauseum up ta 4096 octets 
CMD/STAT octet: 
7161s 4 Si: 2:1i0 
Wo he aS on See SS s 5 
i er © O - Info frame (TI) 
iota QO 1 — Ack of Info (A) 
Hi er 1 © -— Connect request (9S) 
ioaoad? 1 1 - Connect request ack’d (C) 
a Sea ae POLL/DONT POLLS when rcvd, returns an ACK if ecnctd 


a ant VCR) 3--Modulo 2 sequence number valid only 
for | and A frames 
Uu- reserved,set toil 
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Cc wo/p 


the type of frame to respond with 
and 
the state to enter after the 


MODIFYING THE HAMTRONICS EM-5 
FOR 9600 BPS PACKET OPERATION 


STEVE GOODE, K9NG 
140 W. WOOD APT. 314 
PALATINE, ILL. 60067 


Abstract 


Within the last year considerable attention 
has been given to level three linking of local 
area packet groups across the country. 
Experiments using virtual and datagram circuits 
are under discussion. This paper presents an 
interface board and the necessary modifications to 
the Hamtronics FM-5 220 MHz transceiver allowing 
operation at 9600 bits per second (bps) to provide 
a high speed link between the local area networks. 


Radio Selection 


The purpose of this project was to provide a 
high speed radio moden as a testbed for the level 
three linking experiments. A minimum data rate of 
9600 bps with minimum modifications to an existing 
radio were the main objectives. In order to send 
9600 bps data with minimal overhead a radio with 
fast transmit to receive and receive to transmit 
turnaround time was desirable. This implied a 
crystal controlled transmitter with pin diode 
antenna switching. Since the ARRL band plan for 
220 MHz contains allocations for high speed packet 
links a 220 MHz transceiver was chosen for the 
initial experiments. A radio that was still in 
production and available to all interested groups 
was also a prime consideration in selecting the 
Hamtronics FM-5 220 MHz transceiver. This unit 
contains a crystal controlled receiver and 
transmitter providing 7 watts of output power and 
pin diode switching of the antenna. 


Receiver Modifications 


The EM-5 is a EM transceiver so it contains a 
discriminator detector in the receiver. Frequency 
shift keying can be detected using a frequency 
discriminator so it was chosen as the modulation 
technique. The maximum data rate that can be sent 
thru the FM-5 receiver using FSK modulation was 
tested by frequency shift keying an RF generator 
with random data at different data rates and 
observing the received data on an oscilloscope. 
The pattern generated when the oscilloscope is 
triggered on the transmitted data clock is called 
an eye pattern. Figure 1 shows the eye pattern of 
the transmitted data on the top trace and the 
received eye pattern in the bottom trace for a 
9600 bps data rate. One bit period is 
approximately two divisions in length. As can be 
seen in the picture, the received eye is open with 
minimal jitter at the bit crossings indicating 
that 9600 bps data can be sent thru the EM-5. 
Figure 2 shows the eye opening of 12 kbps data. 
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The eye at 12 kbps is beginning to close with 
increased jitter at the bit crossings but the FM-5 
could be used to send 12 kbps data. Figure 3 
shows the eye pattern of 16 kbps data. This eye 
is closed with an unacceptable amount of jitter at 
the bit crossing. This data limit is due to the 
bandwidth of the IF filters in the FM-5 and could 
only be extended by increasing the bandwidth of 
the IF filters. Since minimum modifications to 
the radio were desired the maximum standard data 
rate was set at 9600 bps. The modification to the 
receiver is simply to connect a shielded wire to 
pin 9 of Ul (the discriminator output) which is 
run to post detection filters on the interface 
board. 


The performance of the receiver at 9600 bps 
can now be tested by measuring the the bit error 
rate (BER) of the receiver. The BER of a data 
system is the probability of not receiving the 
transmitted bit correctly. This is normally 
expressed in percent or decimal form. For 
example, a system with a BER of 1 x 10-3 or 0.1% 
has the probability of receiving the transmitted 
bit incorrectly once in every 1000 bits. Bit 
error rate is measured by  canparing the 
transmitted data bits with the received data bits 
and counting the number of errors. The BER for 
packet radio is dependent on the input signal 
strength to the receiver, so a graph of BER versus 
input power to the receiver is the normal measure 
of data system performance. Figure 4 shows the 
BER performance of the FM-5 receiver at 9600 bps. 
Figure 4 shows that at the 20 GB quieting level of 
he , 16-0 Me one conbar lS, PeAgur go a 25) BE 
previously on the TAPR 1200 bps audio modem which 
was reported in QEX (1). Figure 5 is the BER 
performance of the TAPR 1200 bps modem. This 
figure shows that at the 20 dB quieting level of 
the Motorola Syntor radio the BER was measured to 
be 1.7 x 10-2. This shows that the 9600 bps radio 
has a system sensitivity that is approximately 
1.5 dB better than the 1200 bps audio modem. The 
direct modulation of the RF carrier is a more 
efficient modulation technique than the audio 
subcarrier modulation of the 1200 bps modem 
providing a_ slight improvement in system 
sensitivity rather than a degradation which might 
be expected in going to a higher data rate. The 
QEX article shows that the AX.25 protocol begins 
to receive packets at the 10-3 BER and it is 
expected that any linking protocols will also 
begin reception at the 10-3 BER. We can then say 
that a EM-5 modified for 9600 bps operation will 
have a receiver sensitivity about 1 dB better than 
it's 20 @B quieting sensitivity. 
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Figure 1 
9600 bps Eye Patterns 
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Figure 3 
16 Kbps Eye Patterns 
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Transmitter Modifications 


The Hamtronics EM5 uses a phase modulator in 
the transmitter section. The transmitter was 
modified to provide direct frequency modulation by 
removing C25 and replacing it with the circuit 
shown in Figure 6. The varactor and shunt 
capacitor were mounted on the bottom of the board. 
The resistor and capacitor formed a_ flying 
connection to which a shielded lead was attached 
and run to the interface board, The EM linearity 
of this modulator was tested by measuring the 
frequency shift at the output of the transmitter 
with various DC voltages into the modulator. 
Figure 7 shows the EM linearity of this modulator. 
As can be seen, the modulator is linear over a 
3 KHz range. A linear modulator was used in place 
of a frequency shift modulator for two reasons. 
First, Since no modifications were made to the 
receiver IF bandwidth the resulting data system 
should fit into the present 40 KHz channel spacing 
220 MHz band plan. This means that some method of 
controlling the transmitted spectrum must be 
provided in the transmitter. Figure 8 shows the 
resulting transmit spectrum when data is fed 
directly into a FSK modulator. At 40 KHz spacing 
there is still considerable energy which can 
interfere with the users on this adjacent channel. 
By filtering the data in a premodulation filter 
and then feeding it to a linear FM modulator the 
spectrum shown in Figure 9 is produced. This 
spectrum has greatly reduced energy in the 
adjacent channel. The second reason for not 
feeding data directly into a FM modulator without 
premodulation filtering is that the high frequency 
components of the data can excite crystal spurs 
resulting in the transmitter operating at many 
frequencies, some of which may be out of the 
Amateur band. 


Figure 6 
FM5 Transmtter Qscill ator Modi fication 
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The optimum deviation for the 9600 bps data 
system was selected by measuring the RF power 
required for a 10-3 BER at various deviations. 
Figure 10 shows the RF power required for a 10-3 
BER at 1.5 to 5 KHz deviation. Deviation was 
defined as the peak deviation when sending a 1-0 


pattern. From this curve it is seen that the 
deviation for best sensitivity occurs at 3.25 KHz 
deviation. Since the data system should work with 


normal frequency offsets encountered with VHF 
radios due to temperature, aging and voltage 
effects, data was also taken measuring the effect 
of deviation on frequency offset. Figure 11 shows 
the RF power required for a 10-3 BER at 2, 3 and 4 
KHz deviation with up to 4 KHz frequency offset. 
Taking into account the frequency offset 
performance of the receiver and the FM linearity 
of the transmitter the optimum deviation for the 
system was set at 3 Kt. 


Now that we have defined the system deviation 
the protection given to adjacent channel users by 
the transmit splatter filter can be measured. 
Commercial manufacturers of voice radios measure 


adjacent channel protection in accordance to an 
Electronics Industries Association (EIA) 
specification (2) which requires a minimum of 70 
dB protection to the adjacent channel. There are 


no specifications at the present time for data 
radios so we will have to make our own definition. 
The EIA voice spec essentially says to adjust the 
adjacent channel signal strength to sensitivity, 
then raise this level by 3 GB and degrade it back 
to sensitivity by the interfering adjacent channel 
transmitter. We can run adjacent channel tests by 
saying that the data system sensitivity is 10-3 
BER. The premodulation filtered FSK signal was 
adjusted to give 10-3 BER and then this level was 
raised 3 dB. An interfering signal was then 
placed at various frequency offsets and the 
protection provided to this interfering signal was 


measured. Figure 12 shows the protection provided 
to a carrier, a premodulation filtered system 
(splatter filtered) and an unfiltered system (no 


splatter filter) at 9600 bps. As can be seen, 70 
GB protection is provided to a carrier which 
should be similar to the EIA test. 70 4B 
protection is also provided to the described 9600 
bps data system at 40 KHz channel spacing. 
Without splatter filtering only 34 dB protection 
is provided which can cause interference to 
operations on the adjacent channel. 


An additional factor which must be considered 


in packet ‘operation is how the transmitter is 
keyed up and down. Since this is done more often 
in packet operation than voice operation the 


frequent key up can produce a spectrum of its own 
that can be higher in splatter than the data 


modulation spectrum essentially negating’ the 
effect of the premodulation data filter. Once 
again there are no commercial specs for this 


frequent transmitter key up but a logical spec to 
set is that this key up spectrum should be below 
the data modulation spectrum. The interface board 
for the 9600 bps radio contains two DC key up 
Switches which control this key up spectrum. The 
9.1 volt line to the oscillator is keyed up 5 ms 
before the 12 volt line to the drivers and stays 
up for 5 ms after the drivers are turned off. 
This reduces the key up spectrum to an acceptable 
level. The modifications to the transmitter 
require removing Cll, R3 and VRI1. A separate 9.1 
volt regulator with transmit switch is on the 
interface board and is brought into the radio in 
place of the removed parts. 


A final modification to the transmitter 
requires removing R24. It was found that the 
charging of capacitors in the transmitter audio 
gave a spike at about 30 ms after key up to the 
phase modulator. This interfered with the data 
that was being transmitted at that time. Removing 
the audio from the phase modulator cured this 
problem. 
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Figure 10 
Dev. vs Pin 
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Data Randomizer 


Since VHF radios can have frequency offsets 
as large as the chosen system deviation for the 
9600 bps data system, fixed decision levels for 
the received data cannot be set. This problem is 
remedied in this system by assuming a random data 
input and deriving the data decision level by 
averaging the received data. Unfortunately the 
AX.25 protocol does not provide random data so 
some method must be found to randomize _ the 
transmit data and then unrandomize the received 
data back to the original transmit data. This is 
provided on the interface board. A 17 stage shift 
register is configured to provide a_ self 
synchronizing data randomizer. This randanizer 
essentially divides the transmit data by a 
polynanial at the transmitter and then multiplies 
the receive data by the same polynomial at the 
receiver. The polynanial for this randanizer was 
selected to randomize AX.25 data sufficiently for 
transmission over the 9600 bps radios. Although 
this is not a standard maximum length polynomial 
it does sufficiently randomize AX.25 data with a 
minimum of extra parts. The randomizer has one 
drawback in that it requires 17 additional bits to 
be received correctly for the packet to be 
received. Since this is 17 bits in addition to 
the over 1000 bits in a packet this does not 
Significantly change the BER required for the 
system to begin receiving. 


Interface Board 


Figure 13 is a schematic of the interface 
board required for the 9600 bps modifications to 
the Hamtronics FM-5. Ul is a quad op amp which 
provides the 5 pole 5 KHz Bessel filter used for 
the transmit premodulation filter and a 2 pole 5 
KHz Butterworth filter used as the post detection 
receiver filter. The filters were designed to 
give 70 dB adjacent channel protection at 40 KHz 
in the transmitter and to provide optimum BER 
performance in the receiver. U2 and U10 provide 
the 12 v and 9.1 v key up controls. U5 and U6 
form the data randanizer with U7 providing the 
necessary switching between transmit and receive. 
U4 and U3 form a clock recovery circuit necessary 
for proper data randomizer operation. A clock 
lock output is also provide by U4 and U3 which is 
used as the data carrier detect function. U8 
provides a 1-0 pattern to the transmitter during 
receive to keep the oscillator on center frequency 
and ready to transmit. U2 provides a time out 
timer for the transmitter and the data slicer for 
the receiver. Channel frequency and deviation of 
the radio are adjusted by removing jumper 1 and 
shorting jumper two. C26 in the FM-5 is then 
adjusted for center frequency. Jumper 1 is then 
replaced and the deviation on the 1-0 pattern is 
set for 3 KHz. 


Field Tests 


An FM-5 transceiver was modified as described 
in this paper along with a Hamtronics T-51/R-220 
exciter receiver pair. The interface board was 
mounted external to the FM-5 and all control leads 
were run thru a 9 pin D connector nounted on 
back of the radio. The exciter/receiver pair used 


the same interface board as the EM-5 but required 
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the building of a pin diode antenna switch. Field 
tests were then conducted between K9NG in 
Palatine, Ill. and WOTD in Hoffman Estates, Ill. 
which is approximately a five mile path. K9NG 
used the 7 watt EFM-5 and W9TD used the 1] watt 
T-51/R-220 pair. Two TAPR kit boards were 
jumpered for twice clock operation and connected 
via the modem connector. 9600 bps packets were 
then sent between the two stations. Both stations 
used a 1/4 wave ground plane antenna. These field 
tests confirmed the bench tests of the 9600 bps 
radios. The Txd of the TAPR boards were set to l 
resulting in a 20 ms delay for transmitter key up. 
128 byte packets were sent in about 150 ms. These 
packets just open squelch in a normal EM receiver 
and sound like noise bursts. 100 Kbyte files were 
transmitter in approximately one anda_ half 
minutes. 


Modifying Other Radios 


The interface board presented here can be 
used to modify other radios for 9600 bps packet 
operation. As was mentioned in the field test 
results, a Hamtronics T=51 and R-220 
exciter/receiver pair were also modified with 
Similar results to the FM-5. One area that may 
cause a problem with other radios is the 
transmitter key up. Since other radios may key up 
differently than the FM-5 or T-51 the method of 
controlling the key up used for these radios may 
not work for others. If at all possible, the key 
up of the intended radio for modification should 
be observed on a spectrum analyzer and verified to 
not create a large transmit spectrum when keyed up 
at an 8 Hz rate. 


Comments on Higher Data Rates 


The filters on the interface board can be 
directly scaled for higher data rates when radios 
with larger bandwidth IFs become available. It 
should be realized that any increase in data rate 
from the 12 kbos maximum allowable in the standard 
15 KHz bandwidth of an m receiver will degrade 
systen sensitivity in a direct relationship. for 
example if a 96000 bps system was desired the IF 
bandwidth would have to increase by approximately 
10 tines and a 10 dB degradation in system 
sensitivity would be experienced. This means that 
link station separation would have to be decrease 
or transmitter power would have to be increased to 
make up for this degradation in system 
sensitivity. The apparent free lunch in system 
sensitivity that was obtained by going to direct 
FSK will not be available for higher data rates 
and the degradation in system sensitivity will be 
a tradeoff in designing link stations to use these 
higher data rates. 


Conclusions 


The necessary interface board and 
modifications to allow packet operation of the 
Hamtronics EM-5 transceiver at 9600 bps have been 
presented. Field tests have proven the design to 
be workable. Every attempt has been made to 
design this radio interface to be a good neighbor 
in the 220 MHz band. Adjacent channel protection 
ratios were measured for the system and provide a 
minimum of 70 GB protection to the adjacent 
channel users. 


Since the EM-S provides a maximum of 7 watts 
of output power, linking groups may be interested 


in designing a power amplifier. This power 
amplifier would have to be designed to provide 
fast antenna switching and proper key up. Future 


projects could also include a radio designed 
specifically for 9600 bps packet operation or 
higher data rates. 
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Abstract 


How Packet Radio could greatly improve the 
interactive capabilities of Distance Teaching. 
Some views on how Packet Radio could improve the 
delivery and efficiency of Distance Teaching in 
Less—Developed Countries. 


Definition 


One problem every nation faces is delivering 
some sort of education to its citizens no matter 
where they are: those in remote or sparsely- 
populated areas; "those severely constrained by 
religious or other traditional social factors 
(e.g., women, or members of low caste in some 
countries) ."1; the handicapped; refugees; 
prisoners; etc. One means of dealing with this 
situation is the use of Distance Teaching. 
Distance Teaching is defined by Joseph N. Pelton 
as a “multimedia educational process in which the 
teacher and learner may never meet face-to- 
face. This form of education has emerged 
largely because society has not been able to 


satisfy needs through traditional educational 
structures."2 Distance Teaching is not new--even 
to this country--but it seems to be gaining 


renewed prominence, especially with the advent and 
promise of satellites. (The reader is referred to 
OSCAR 10 experiments last year,3 and the UoSAT- 
OSCAR 11 proof-of-concept demonstration in January 
this year.4) While Distance Teaching is of 
increasing importance in the Developed Countries, 
this report is aimed at the Less—Developed 
Countries. 


Interactive Distance Teaching 


For Distance Teaching to really reach its 
full power, it needs to approach as near as 
possible the face-to-face, interactive conditions 
of teacher-to-student. Packet Radio makes this 
goal the most affordable yet. Because of the 
following important features, I believe Packet 
Radio can bring interactive Distance Teaching to a 
point educators never even hoped for before: 


Costs can be held down with the bare 
bones, minimum components as follows: a personal 
computer and display of some type, a Terminal Node 
Controller, a transceiver, and an antenna. 


Ts 


2. Brands of computers can be mixed because 
the use of ASCII code is the great equalizer 
between computers of different types. 


3. Enough Digipeaters (Packet Radio stations 
as detailed in the first item, above) can make the 
system's range nearly limitless. 


4.52 


4, This medium is digital, almost 100% 
error-free communication. This opens up whole 
aspects of information transfer that were simply 
not feasible prior to this time. Today, if it can 
be digitized, it can be sent and, tf Tk “can. be 
sent errorlessly, then data transfer suddenly 
becomes a far more valuable and cost-efficient 
exercise than before. 


Price 


Cost of a minimum Packet Radio system will 

according to hardware sophistication, 
features, and whether peripherals are added. I am 
currently conducting a survey of Packet Radio 
users, but it is too soon to publish any reliable 
information. However, the cheapest arrangement 
reported so far was $525 with some used components 
and the most expensive was $2,125. The average-- 
again, from a very small sample--is $1,025. 


vary 


It should be noted, too, that a savings can 
be made if the Terminal Node Controllers are 
purchased in kit form and assembled on site. This 
would be an excellent exercise for a science or 


electronics class. For nations that permit 
amateur radio activity, it might be possible to 
obtain volunteer time and equipment such that 


initially only the Terminal Node Controllers need 
be purchased. This would be an especially good 
approach if a government wished a trial of the 
Packet Radio concept before committing to it. 


One of the nice surprises in store for an 
agency considering the costs of a Packet Radio 
installation is no new facilities need be 
constructed. A Packet Radio station requires no 
more space than a large closet--so any packet 
station could reside in the main ministry of the 
capital as well as the smallest classroom in the 
COUNEEY. 


when calculating costs, it must be 
that once the Distance Teaching chores 
the equipment should never 


Lastly, 
remembered 
are over for the day, 


sit idle. The hardware can be utilized in many 
additional, exciting, and valuable ways. For a 
classroom entering the electronic age, here are 


two perfect instruments to be considered as tools, 
as objects of study themselves, and as assistants 
in the classroom: the computer/display and the 
transceiver/antenna. 
Applications: Interactive 

Here are but some of the possible uses of 
Packet Radio for interactive Distance Teaching: 


--Upgrading, improving, or enhancing the 
skills of the teacher/aide already on site. A 
master teacher in the central district could 
provide lessons for presentation by an instructor 
in some isolated area. This could inject new 
ideas or skills into the repertoire of a 
teacher/aide/tutor. The person in the remote part 
of the country would receive instant feedback 
regarding the correct use or presentation of the 
lesson prior to giving it to the class. This is 
the type of interaction that improves teaching 
efficiency: sort of a "remote in-service." 


--Monitor students' academic progress with 
daily or hourly checks for rapid diagnosis and 
remediation. Again, the experienced teacher 
interacts from a distance to assist the new or 
unsure teacher on how best to proceed with a 
student's lessons. 


--Personalized lessons based on students' 
performance (with individualized instruction on 
subjects as varied as reading or engine repair). 


--Academic credit. Students could "take 
classes from schools all over the country : 
even earn high school, corneas! and graduate level 
credits through the system." 


--Timely contact with the teacher from. the 
provincial or capital offices. This would 
facilitate important information reaching the 
teacher quicker than the postal system (which is 
slow enough in Developed Countries!). Bulletins, 
pertinent literature reviews, even disaster 
warnings could reach the school with ease and 
reliability. 


--Sending up-to-the-minute information from 
the teacher back to the central office. This 
would provide the up-country instructor with a 
means to obtain advice, support (moral or 
pedagogical), or emergency assistance in a most 
expeditious way. 


--Teacher-to-teacher contact and support. 
Communication with one's colleagues is important 
in any endeavor and especially when one is new or 
inexperienced to the job. With Packet Radio, an 
opportunity to seek the company of someone else 
"in the trenches" is readily available 24 hours a 
day. For this (and for digipeating), a Packet 
Radio station ideally should remain up-and-running 
every hour of the day where possible. 


--Bulletin board service. With the 
availability of a BBS, many of the above types of 
communication would be enhanced. 

Applications: The Computer 

No matter what make or model it is, there are 
a myriad of things a personal computer can do for 
the teacher. As a tool (depending upon 
configuration, memory, and time available for use) 
it can inventory, keep records and grades, perform 
EMAIL and store and forward messages, store 
programs, control environmental conditions of the 
classroom/school, and word process. "Information 
retrieval may be used directly by students 


as a quasi-library facility. . . . [And, not 
least, ] students interact with the computer 
without intermediaries for the express purpose of 
increasing their knowledge or skills in some 
school subject. 16 


As an object of study, there are spreadsheets 


and word processors, programming languages, 
input/output, data retrieval or computer-to- 
computer communications, Simulations, graphics, 


artificial intelligence, etc. 


It can become an assistant to the teacher by 
taking small groups of students aside to work or 
play while the teacher does large-group 
instruction with the rest of the class. It can 
also free the teacher by providing tutoring, 
drill, and practice or review, not to mention 
administer tests of placement or comprehension. 
Applications: The Radio System 

Here--to a much lesser extent--we also have a 
tool (depending upon the electronic skill and 
confidence of the operator). It can locate other 
sites, page people, perform RTITY and Slow Scan 
Television, etc. As an object of study it is 
perfect for analog and digital electronics, 
antenna theory and construction, Orbiting 
Satellite Carrying Amateur Radio (OSCAR) and the 
necessary tracking (great for applied math), etc. 
As an assistant it too can separate a small group 
of students off to entertain or instruct. 


It must be mentioned this new wonder of our 
lives--Packet Radio--need not, indeed should not, 
be limited to use only by educators in the school. 
Presentations could be done after hours that offer 
courses, lectures, or updated developments of 
interest to other members of the surrounding area 
such as farmers, merchants, hobby groups, 
investors, etc. 


Other Considerations 


Before embarking on this path for improving 
Distance Teaching, three factors must be 
considered: environmental, sources of power, and 
human resources. 


Environmental: As great and wonderful as 
computers are, at this stage in their evolution, 
they can quickly be felled by 

heat, dust, humidity, vibration, and 

mechanical shock. .. . they are not 

often moved, and when they are, are 
moved with care. Environmental 
constraints can be compensated for in 

two ways: the environment itself can be 

controlled by means of air conditioning, 

SLC. Or computers that are more 

resistant to environmental hazards can 

be purchased; such computers are 

available, having been developed for the 

Armed Forces for use in uncertain field 

conditions, but are quite expensive in 

comparison to the commercially available 

computers. 7 
On the other hand, lap board computers, such as 
the Radio Shack Model 100 which have all the 


4.53 


necessary components enclosed, could be a distinct 
possibility. The only drawback is a small display 
and limited memory for storage, but even the 


memory can be expanded with cassette tape and 
recorder. 
Sources of Power: Many schools in remote 


areas of the world are without power. Those that 
are blessed with it often find it unreliable or 
fluctuating more than computers can tolerate. 
Alternatives have been studied, especially in 
regard to "appropriate technology.** Agencies such 


as the Peace Corps, Volunteers in Technical 
Assistance, and the Amateur Radio Relay League 
actively seek new and inexpensive designs and 
creations in the area of power supplies for 
electronic equipment. Various types oni 
generators, battery configurations, and solar 
panel arrays exist now and the market grows at a 


rapid pace. 


Resources: Whether it is the 
themselves, aides, or dedicated 
operators, some sort of training must occur before 
a system such as this could be put in place. A 
way to forgo this expense of time and money would 
be to limit the placement of the hardware to the 
classroom or school which had a science teacher on 
Site. Even so, I contend the training necessary 
does not have to be extensive or lengthy because, 
as hardware engineering continues to output more 
and more sophisticated equipment, the operator 
needs to know and do less and less. Add to that a 
good software program to achieve minimum levels of 
operator interaction and the prerequisite skill 
(if not anxiety) levels would further reduce. 


Human 
instructors 


Conclusions 

Packet Radio most certainly should be 
considered as a delivery system for Distance 
eaching. Its technology could make Distance 
Teaching truly interactive in every sense. Its 


costs are certainly competitive with any present- 
day delivery system and its future use via 
satellites is ensured. Added to that, a Packet 
Radio station site has a computer and transceiver 
as tools and teaching aids when not in use with 
Distance Teaching. Most Distance Teaching 
projects are aimed at adults, but I must emphasize 
there's no reason primary-age students could not 
be well served by the equipment and concepts in 
this proposal. 
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Abstract 


A review of packet growth since the Third 
ARRL Networking Conference is followed by 
a discussion of anticipated expansion of 
packet activity during the next year. 


A framework for orderly growth is presen- 
ted, based on the above observations. 


1984 

associations not withstanding, 
1984 was a year which saw tremendous 
growth in Amateur packet radio in the 
United States as well as the rest of the 
world. This growth included technical 
advancement addition to a vastly 


swelled weer base. 


Orwellian 


in 


On March ist, UcSAT/OSCAR-11 blasted into 
SCEbLE, carrying a PACSAT-like prototype 
Digital Communications Experiment (DCE). 
The DCE was publicly demonstrated at the 
Pacific Telecommunications Conference in 
Hawaii in January, 1985, via a store-and- 
forward technique. Communications were 


supported between England, California and 


Hawaii during this operational test. 

In mid-summer, the 23rd Olympiad was 
hosted in tos Angeles. The Football 
games were held in Stanford, near San 
Francisco; and Amateur packet radio was 
used to carry hundreds of messages re- 


lated to the Stanford events. 


HF packet has been used on 40, 30 and 20 
meters to provide a primitive linking 
capability between Arizona, Massachusetts 


Washington, D.C., and other areas. 


Meteor scatter technigues were tested on 


&-meters, resulting in reliable, if slow, 
data transfer between Iowa and Washing- 
ton, De. 

The WORLI bulletin board/message forwar— 


ding system has gained widespread accep- 
tance in the packet community, furthering 
the "networks without networking" experi- 
mentation. 


The sheer number of packet radio partici- 
pants has increased between four-and ten- 
fold, depending on whose figures you 
believe. TAPR slone placed in excess of 
100 TNCs per month during calendar 2984, 
and the rate has not slackened as of this 
writing. 
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83734-2888 
The ARRL Ad Hoe Digital committee, wor- 
king with in&rested packet groups, nas 
been sponsoring a lively debate and re- 
Sults-oriented "contest" between the two 
major viewpoints for Networking —- Yir- 
tual Circuits and Datagrams, the former 
represented by the AxX.25 Level Three 


approach and the latter by TCP/IP. 


Early 1985 

1985 has opened with a "bang" for packet 
rade, The two fronts of packet expan- 
sion, technical advancement and market-— 
ing; have been addressed, and rather 
dramatically. 


Stave Goode, K9NG, of the Chicago Area 
Packet Radio Association, has developed a 
9600 bps modem capable of working within 
a 20- to 40-kHz bandwidth using straight- 
forward direct FSK techniques. Steve's 
work opens the door for widespread use of 


9600 bps (and faster) packet data  chan- 
nels through the virtues of simplicity 
and economy. In Gonjunction with this 
efrort;, TAPR. 2S dedicating  sigqnaticant 
resources to the development of an inte- 


grated modem/rf deck for 9600 bps packet 
operation on the 220-MHz Amateur band. 


On the marketing front, a major manuafac- 
turer of Amateur radio equipment, Heath- 
Katy has entered the packet fray. Un- 
veiled at the Miami Tropical Hamboree, 
and iater at the TAPR Annual Meeting, 
both in February, 1985, Heath has pro- 
duced a “TAPR-clone™ TNC kit to sell for 
under $300. 


Heath has indicated that a major share of 
their current revenues are generated vy 
their computer product line, and packet 
is a logical way to link the computer and 
amateur radio markets. While this may 
seem obvious to most packeteers, Heath is 
the first manufacturer with a significant 
presence in both markets (and perhaps the 


only manufacturer in that category!) to 
commit resources to the packet market- 
place. 

There are indications that other manufac-— 


turers may be entering the Amateur packet 
radio arena; at the least, it seems rea- 
sonable to expect innovative, alternative 
packet hardware and to 
available during 19985. 


software become 


What Does AU This Mean? 


Packet information available to TAPR 
suggests that there is starting a consi- 
derable influx of newcomers to Amateur 
packet radio. Many of these people are 
non-technically oriented. Their inte- 
rests range from trett ic handling, 
through emergency communications, to 
simple curiosity. 


Aa equipment becomes available that is 
easy to integrate in the average ham 
shack, and documentation is written to 
make packet operation easy to understand, 
the influx of less technical members of 
the Amateur community to packet radio 
will likely increase. In many areas of 


the country, local packet activity has 
seemed to reach a critical mass, with 
newcomers appearing on a_ weekly, some- 
times daily, basis. 

These people want to operate packet, not 


devel They aren't interested in a 
network that doesn't exist, or potential 
that is untapped. An organizational 
structure not unlike the present 
VHF and UHF repeater system may emerge, 
however, with a user community willing to 


from which will derive direct 


benefit. 


they 


We are reaching a point in time that will 


require packet radio to deliver on its 
promises. 
Thus, we forsee a significant impact on 


Amateur packet activities 


from the 


On the technical front, we find that many 
areas, particularly those areas that make 
extensive use of the digipeating facili- 
ties offered by the AX.25 Level 2 proto- 
col, are experiencing saturation. This 
results in long delays, multiple retrys 
and other assorted negative factors. 


While 1200 bps is a significant 
over other widely used Amateur 
signalling rates, it is unreasonable to 
expect this SOrE -Of bandwidth to 
accomodate a large population, especially 
if confined to one or a few channels. 


advance 
digital 


Furcher, as initial Network Level 
protocols are implemented and more packet 
stations are able to access the 
facilities offered on these networks, 
congestion is bound to increase. 


Thus, we see a significant impact on 
Amateur packet operation from a techncial 
standpoint. 

A Plan For Growth 

We are familiar with much of the 
potential of packet. When multiple, 
medium- to high-speed links blanket the 
continent, we will be able to dump 
megabytes’ worth of data with ease and 
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confidence. Real-time 
computer communications 
Me, 


video, inter- 
the sky's the 


But this is only potential. If we invoke 
this vision too often to the uninitiated, 
they will begin to believe we are 
speaking of the present, not S30R@ 
(hopefully not distant) future scenario. 
Disallusionment can only feed the fires 
of the scoffers and detractors. 


The problem at hand is how to build to 
this kind of a system in manageable 
steps, each step taking us closer to our 
eventual goals, yet with the efforts 
having long-term usefulnesge as well as 
near-term effectiveness. And of course, 
the bill to develop and produce these 
evolutionary goals must be small enough 
to be absorbed by the packet community 
existent at the time the step is taken. 


We do not presently have the manpower, 
technical experience nor money to put up 
a blanket-the-nation high-speed network. 
We don't even have protocols tested in 
the Amateur environment upon which to 
build such a system. A suggested course 
Of action: 133 


1) Make a decision on Network Level pro- 
tocol . Work together to implement this 
provecol, prefereably on standardized 
hardware that is both capable of suppor- 
ting Network and Transport decisions and 
doing so on multiple channels running at 
9.6 kbps to S36 kbps. 


2) Design rf decks that are easily built 
and adjusted, low in cost, and capable of 
operating with existing packet radio 
controller equipment at 9.6 kbps. 


3) Get multiple channels coordinated and 
operational between metropolitan areas 
that have packet communities to support 
them, Such channels should operate at a 


data rate of at least 9.6 kbps. Future 
operation at 56 kbps should be planned. 
Eventual operation at 256 kbps to 2 Mbps 


should be anticipated. 


4) Establish HF gateways in major areas 
of packet operation. 300. bps/200 Hz 
shift has become standard on 40/30/20 
meters iy. the: Us: Petitioning of 
regulatory bodies to allow operation at 
1200 bps should be done at the earliest 
practical date, and waivers to allow 
technican-class licensees digital traffic 
to be "linked" on HF frequencies should 
be requested. 


5S) As regional networking occurs, a si- 
multaneous national effort should be 
undertaken to develop and fund sites that 
do not have the packet population to 
support a local network node, but which 
lie on a route that will benefit a major- 
ity of packeteers by providing a backbone 
service. 


For example, there is a sufficient 
of 2ctivity in Dallas, Little: Rock; 


ievel 
Okia- 


homa City and St. Louis to support net- 
work nodes, but insufficient activity 
between these regions to support linking 


them together . 
a major 


Yet, if they were linked, 
segment of a transcontinental 


backbone would be in place. Thus, at 1s 
to the long-term benefit of packeteers 
in, say, Fiorida (for example) to. see 
this aink established. A mechanism to 


fund such development should be examined. 
TAPR is currently looking at some schemes 
to accomplish this. 


The point here is that parochialism must 
be set aside for the long-term benefits 
of ali concerned. 


&) As technical development continues, 
the slcower-speed systems (9.6 Kbps to 56 
Kops) used for linking can be replaced by 


higher-speed nodes, with the retired 
equipment pressed into feeder service in 
the larger metropolitan nodes. This 
suggest3 that. a form of :contribution ‘to 
the national effort may be as equipment 
“loans” for temgorsary service in remote 
areas. 


Assuming such a scenario or one broadly 


similar, become5 fact: the near-term 
technical goals that appear achievable 
are; 


4) Development of an integrated 9.6 kbps, 
low-cost 220 MHz radio/moden. Such a 
system is currently under active develop- 
ment by TAPR, in coordination with reg- 
ional groups across the US. Expect some— 
thing to be in the testing stage during 
the summer of 1985, with general availa- 
bility as soon as testing is *'completed" 
(is any technical project really com- 
pleted?). 


2) Development of a multi-ported Network 
Node Controller capable of establishing 
Levels Two, Three and some subset of 
Four. A minimum capability of two ports 
(for a remote Location that is Simply 
part of a backbone> and ae possible 
expansion to as many as eight ports may 
be a reasonable goal. 

Mike Brock, extensive 
research and 


WBGHHV, has done 

development of a multiple 
Z80-based system capabie of reaching 
these goals. This project has been put 
on temporary hold pending the outcome of 
a decision for a Networking Protocol. 


With the 
becoming 


now 
which 


many new 
available, 


microprocessors 
and ror 
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extensive development tools exist, 
design will be undoubtedly be revised in 
the coming months. Again, TAPR has 
identified such a controller as 8 high - 
priority project, to be worked on in 
parallel with rf and modem acvances. 


this 


On the non-technical front, newcomers to 


the packet field must be encouraged and 
instructed in the proper operation of 
Amateur packet radio. Operating proce- 


dures must be tailored to the environment 
as it exists today. 


date is a waste of channel 
resources to have all stations turn on 
their CW ID function on VHF. Beacons 
every few minutes telling the world you 
will be out of town for the next two 
weeks similarly have no place. Dumping 
100k bytes of files during prime 
operating hours on an otherwise busy 
channel is Similarly hard to justify. 


For example, 


While such abuses of common 
courtesy may seem absurd, 


operating 
these and other 


practices like them occur all too  fre- 
guently on our existing, embryonic net-— 
works. 

We must all work together to educate 


newcomers and encourage the use of proper 
packet operating procedure. 


Conclusion 


1984 was 
Amateur 


a year of tremendous growth in 

packet radio. 1985 has started 
off with even more promise of growth, 
injecting into our ranks a large number 
of non-technically oriented Amateurs. 


Network protocols must be agreed upon and 
implemented. Hardware to Support wider 
bandwidths, especially in the areas of rf 
decks and modems, must be designed and 
made easily available. 


A coherent plan to establish regional and 


an eventual first national network must 
be determined and implemented. 

Parochial interests must be moderated 
with recognition of the needs of the 
packet community as a whole. 

Growth must be planned (for, newcomers 
educated and proper packet procedures 


encouraged for the maximum benefit of ali 
packetesrs while we develop the technical 
resources to handle our exploding 
operational requirements. 


PACKET RADIO AND THE NATIONAL HURRICANE CENTER 


Joel |. Kandel ,KI4T 
5463 S.W 92nd Avenue 
Mam, FL 33165 


(305) 596-9373 


Abstract 


Amateur radio operators in South Florida are 
exploring the capability of Packet Radio to pro- 
vide the National Hurricane Center wth high qual - 
ity weather observational data, and in turn trans- 
mt tinely forecast infornation fromthe Hurricane 
Center to effected areas. 


Preliminary Tests 

Qn Septenber 10, 1984, W4SS, ARRL Section 
Energency Coordinator for South Florida called 
for a Packet Radio test between and anong a num 


ber of county Energency Operations Centers (E0C's). 


Q that date, a packet station was taken 
to the National Hurricane Center by KI4T, and 
an authentic veather bulletin was transmtted to 
the various E0C's partici pating in the test. 


The weather bulletin text was received i n- 
tact as far away as Ml bourne, Florida, by N2WX, 
a distance of 220 mles, as well as by packet sta- 
tions in Dade and Broward Counties, Vést Palm 
Beach, Stuart, and Ft. Pierce. This initial test 
of packet weather bulletin transmssion fromthe 
Hurricane Center was in large neasure responsi - 
ble for sone of the above nenti oned nuni ci pal - 
ities purchasing packet controllers and dedi - 
cating conputers to them 


Although the text was nanually entered on 
a termnal at the Hurricane Center, it portents 
the day when autonatic weather text transmissi ons 
becone a standard service provided by the ama- 
tuer radio connuni ty. 


Backgr ound 

In order to better understand how packet 
radio might function superbly at the NHC, let's 
first look at how the NHC itself functions. 


The Center is operated under the j uri sdic- 
tion of the U.S. Departnent of Conmerce Nati onal 
Qceanographic and Atnospheric Adninistration. Its 
function is to nonitor the fornation of hurri- 
canes in the Atlantic, track their progress, and 
issue current veather infornation in the form of 
advisories, bulletins, updates, and forecasts to 
the effected areas and to the country at large. 
Incoming data, at the average rate of 4,000 
pieces or “products” per 24 hour period, cone 
from four najor sources: (1) hurricane hunter 
aircraft, (2) weather satellites, (3) ships, 

(4) bouys, and (5) local land observati ons. 


Hurricane hunter aircraft are nost use- 
ful for neeting the hurricane out where it is 
formng, over water. The aircraft can send back 
nany kinds of data as they fly directly into the 
eye of the stormand take sone very sophisti cated 


neasurenents. Like all aircraft, what goes up nust 
eventually cone down. The plane can't stay indef- 
initely, so its observation tine is l|imted. 


Véather satellites, specifically the GO 
series, are set in geo-synchronous orbit, 23, 400 
miles above Earth, so that they are stati onary 
wth respect to the Earth's rotation. Vhile‘these 
satellites have the capability of photographi ng 
a hurricane fromthat position on a constant basis, 
it is literally an "overview and tells little 
about what is happening on the ground. Last 
hurricane season the East Coast GEG satellite 
nal f uncti oned. NOMA nust now tine share one 
satellite between the East Coast and the Vést 
Coast of the United States. 


Shi ps' observations are collected in 
Vashi ngton and are transmtted via | and-line to 
the NHC. Wile it is a source of good, first hand 
observational data, their positioning and presence 
is purely random and there is no way of knowng 
when or whether any ships at all wil be present 
in a given veather area. 


Buoys located in the Gulf of Mexico and along 
the Atl antic Coast send back weather data through 
satellite. Their data is exacting, but is strict- 
ly coastal. No buoys are | ocated in internati onal 
or foreign waters of the Cari bbean. 


Local observations are still a nost i nportant 
tool for forecasting novenent of the storm Local 
veather bureaus abound throughout the country and 
the Caribbean, but are far fever in nunber than 
anateur radio stations. Wth mininal packet radio 
equi pnent, anateur stations can send vital weather 
data back to the Hurricane Center for processing. 


Anateur Radig at the NHC 


For the past six years, anateur radio has 
pl ayed an inportant part in the gathering of real - 
tine veather data for the Hurricane Center. | 
enphasi ze gathering rather than dissem nati on 
because the original and prinary reason for an 
anateur station at the Center was to bring data 
into the center, rather than rel ease i nfornati on 
fromthe Center. Most are famliar wth NOM“ 
Véather Radio, broadcasting from |ocations through- 
out the country on the VHF frequencies of 162. 40, 
162. 475, and 162.550 Miz. Fewer are famliar wth 
the national AFOS Network. AFOS is an acronymfor 
Autonated Field Operations Services, and con- 
sists of a nationwde netvork of neteorl ogical off- 
ices, connected to one another by a telco net- 
work of data lines and mcroveve relay stati ons. 


Wile the AFOS system provides a high speed, 
4800 baud link anong the nation’s weather facili- 
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ties in good weather, the system quickly degrades 
in severe weather, wth flooded phone lines and 
mcro- wave path loss resulting in the effected 
area being out of touch when they need the system 
nest. 


The Cari bbean Islands are less equi pped to 
keep in neteorlogical touch wth the US., and 
infornation paths degrade even nore frequent! y 
and easily than in areas of the United States pro- 
per. 

It is for these reasons that the NHC has a 
pernanent anateur radio station, donated by the 
Dade County Anateur Radio Public Service Corps 
(ARPSC). The station is nanned on a 24 hour basis 
when the Center requests infornation froman eff ec- 
ted area. 


Qperating Procedure 


Anateur operators at NHC usually nonitor the 
Hurricane Watch Net on 14,325 Mt., and two neter 
sinplex frequency. Anateur operators in the connunr- 
ity fan out across 40 and 80 neters, checking into 
energency nets operating fromthe effected area 
such as the Gilf Coast Hurricane Energency Net. 


As nany as 125 stations distributed from Mx- 
ico to the Florida Panhandle nay check in during 
a given hurricane in the Gulf. These stations are 
asked to suppl y the Mam station wth neteorol og- 
ical data such as rainfall anount, wnd direction, 
and wnd speed. These data, once received by the 
Mam station, are relayed to the NHC on the tvo 
neter si npl ex frequency. 


The weather data is given to the forecasters 
who feed it into their nain conputer, which con- 
tains data fromall previous hurricanes, as vell 
as incomng data fromthe other aforenenti oned 
sources. 


The conputer develops a predictive behavi or- 
al nodel of the hurricane fromthe data, and pro- 
duces a forecast of the future path of the storm 
The forecast is sent out over the AFG netvork, 
NOMA Véather Radio, and also 20 neters, by the 
anateur operator on duty. 


For nany Caribbean Islands, the anateur 
bulletin is the only forecast infornation they wll 
ever recei ve. 


In 1949, during Hurricane David, Doninica | ost 
its entire weather station at the national air- 
port. It blew away just five minutes after the ana- 
teur operator there announced that he was evacu- 
ati ng. 

In 1980, during Hurricane Allen, St. Lucia 
was totally devastated, and the Prine Mnister 
directed the entire relief effort fromthe only 
anateur radio station on the island. 


Packet radio has the potential to nake both 
gathering and dissemnation of tinely weather in- 
fornation to and fromthe Hurricane Center infin- 
itely nore efficient, for a nunber of reasons. 


As Bob Neben, K9BL (Rinaldo 1984: 79-82) 
poi nted out in his paper on Packet Radio and 


Energency Connuni cations, the great advantage a 
packet network has over a directed phone net or 


C.W net is that it can take a "bus" confi guration. 
This neans that any station can transmt or 
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recei ve on the sane channel at any tine, w_thout 
the necessity of a net control station and wth- 
out interupting the connuni cations of other sta- 
tions on that sane channel. Packet radio wll 
allow incomng weather infornation from anateur 
stations in an effected area to be transmtted 
on one frequency, essentially at the sane tine, 
wth mninal interference. 


Speed 


Wile previous data had to be gathered 
laborious! y on 40 and 80 neter phone through tor- 
tuous static crashes and QRM packet promises to 
drastically speed up the flow of infornati on. 


Currently, the standard rate of transmission 
used on two neter packet frequencies is 1200 baud, 
or the equi valent of 1200 words per minute! This 
rate 1S nowhere as fast as current equi pnent all ovs 
though the FCC requires a naxi num bandw dth on tvo 
neters of 20 Ktyz. 


Still, 1200 words per minute is roughly nine 
tines faster than nornal conversational speech, 
and probably 18-20 tines faster than passing 
phone traffic at witing speed; especially traffic 
that contains nunerical statistics, passed on 80 
neters, at night, through bad weather cells. 


Accuracy 


Since packet radio has built into it the abil- 
ity to detect errors in reception, it is possible 
to send and receive perfect copy, an absolute nust 
wth weather data. 


Man- Hour Efficiency 

Since the Hurricane is nanned on a 24 hour 
basis naking nanpover a premumconnodity, the 
veather data would be nuch nore accessible to the 
forecasters if received autonatically. The packet 
station at the Hurricane Center wll include a 
printer, allowng forecasters to access incomng 
data wthout having to disturb the anateur oper- 
ator, who nay be busy on a phone frequency. 


If a hurricane is headed toward the South 
Florida area, anateur connunicators are at a 
premum nanning shelters, nunicipal facilities, 
and other volunteer agencies. The key word here 
is autonati on. 


Incoming Véather Data 


Plans are currently in process to gather 
veather data by autonated neans, digitizing it, 
buffering it, and transmtting it back to the Hurri- 
cane Center. The Heathkit 1D-4001 Digital Véather 
Center wll be used in these tests, since it con- 
tains conputer interface capabilities through a 
built-in 25 bit bus. 


Data can be transmtted back on a regular ba- 
Sis, or upon the NHC packet station connecting to 
the renote weather stations on a rotational basis, 
and querrying them i ndi vi dual I y. 

It is forseeable that the AFOS weather net- 
work could eventually be augnented by anateur sta- 
tions throughout the country, tying into it at var- 
lous nodes, and adding support to other naj or 
veather offices, beside NHC 


Qut goi ng Weather Forecasts 


From prelininary discussions wth the tech- 


nical personnel at the Hurricane Center, tests 
wll be conducted in the near future interfacing 
the NHC AFOS termnal to packet radio. 


The AFOS data is transmtted to a nunber of 
subscribers at a large variety of baud rates, 
taking into account the various types and vi ntages 
of termnals in use at the other end. Approxi nate- 
ly 500 transmssions of weather products are nade 
fromthe Center each day, to civilian, narine, and 
military end users. 


A nicroprocessor wll have to be able to 
recogni ze a given weather bulletin heading, in 
order to select out the advisories pertinent to 
the effected area, and destined for civilian con- 
sunption. Exanples of actual weather data texts 
and their headings are given belowin the addendum 


Once these bulletins are culled fromthe nass, 
they can then be transmtted over packet radio to 
the anateur population at large who can then dis- 
semnate it to the appropriate authorities. 


Itis antici pated that these bulletins would 
be sent out on both HF and VHF bands, to insure 
that it gets to the effected areas which nay be 
out of VHF range. 


Vérk is currently under way to install Gator 
J, 9600 baud | evel three intercity packet | ink 
throughout Florida. Hgh speed links of this type 
wll facilitate the routing of weather packets. 


The enclosed nap indicates four najor packet 
paths of prinary concern to the Hurricane Center. 
These are the Atlantic Coast, the Gilf Coast, the 
Florida Keys, and the Caribbean. If one of these 
had to be singled out as being nost critical it 
would be the Caribbean, where adequate weather 
connuni cations are alnost nonexistent. 


The anateur radio antennas at the Hurricane 
Center are about 150 feet high, and offer excellent 
sinplex two neter connuni cations to the surrounding 
areas. It is anticipated that a good H lind will 
be needed to both the western end of the Gif 
Coast, and the Caribbean, wth gateway stati ons 
in those locations able to transl ate HF packet to 
VHF, and vice-versa. 


Practical, Non-techni cal Consi derati ons 


The NHC is a federal agency. As such, its 
connuni cations are regulated not by the FCC but 
by the IRAC, the Interdepartnental Radio Advisory 
Conmittee. [RAC is conposed of representatives from 
all the federal agencies, including the mlitary 
and the FCC, and would have to give its consent to 
the transmssion of AFOS infornation on the Ana- 
teur Radio Service. Paragraph 97.113 of the FCC 
regul ations prohibits the rebroadcasting of in- 
fornation on anateur radio frequencies, though 
the FCC has granted a limted nunber of Speci al 
Tenporary Authority (STA) authori zations for the 
transmssion of NOM veather bulletins over two 
neters. 


An STA application nay be filed previous to 
conducting these tests. 


It renains a grey area Wthin the FCC anateur 
regul ations wth respect to the status of packet 
di gi peaters as renote stations, as repeaters, or 
even as beacon stations. The FCC should clarify 
their statusinthe near future in response to pe- 
titions now before it. 


In any case, the operation of these stati ons 
wll usually occur in an energency situation 
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In any case, the operation of these stati ons 
wll usually occur in an energency situation, when 
there exists "... the inmediate safety of life.. 
or the innedi ate protection of property." Under 
these circunstances, the operation of a packet 
veather network is very feasible. 


Future Technical Consi derati ons 


Mich renains to be done forma techni cal 
standpoi nt. While digipeaters are springing up 
nicely throughout South Florida, not all of them 
are capable of running on energency backup pover, 
energency pover is essential to insure reliability 
of pathvays. 


Packet stations are beginning to infiltrate 
the Florida Keys, a crucial connuni cations area 
in tines of severe veather. But as of yet we do 
not have an established path to Key Vést, the 
southern nost key as vel! as the nost densely 
popul ated one. 


Experi nentation wth packet on HF SSB fre- 
quencies iS proceeding along, but few stati ons 
are active on HF packet, crucial to the packet 
veather net. 


Software connand paraneters have to be es- 
tablished on the Tucson Anateur Packet Radio Term 
inal Node Controller (TNC), the predomnant unit 
used in the South Florida area, to optimize the 
flow of data in both directions, as well as to 
configure the network. And last but not | east, 
anateur stations have to be recruited to actively 
participate in the collection of weather data, and 
its transmssion to the Hurricane Center. 


Packet nust be introduced into the Cari bbean, 
and gateway stations established wth reliable 
energency power capability. 


Sunnar y 


Vé have | ooked at a unique application for 
anateur packet radio, that of suppl ying crucial 
veather infornation to the National Hurricane Cen- 
ter fromsevere weather areas, and reciprocally, 
suppl ying effected areas wth critical forecast 
bul | etins when traditional sources of weather in 
fornation fail. 


Although not every connunity has a Hurricane 
Center in the neighborhood, a conparable weather 
network can provide backup infornation to any vea- 
ther bureau office, in fact all along the AFG cir- 
cuit. The sheer nunbers of anateur stations po- 
tentially equi pped to do so is enornous as com 
pared wth traditional sources of weather data. 


Packet radio allows for this infornation 
to be transmtted error free, wth little or no 
loss of infornation over nultiple, si nul taneous 
paths, and wth a high degree of speed and auto- 
nati on. 


This type of "high-tech" anateur radio par- 
ticipation can only strengthen our inage in the 
connunity and insure the continuity of our hobby. 
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“WETNET” 
MAJOR PACKET RADIO PATHS 


for the 
NATIONAL HURRICANE CENTER 


AL 
TX LA MS y—ta 
a TY & 
* 
* v, —\ 

* 
eae 
/, GULF OF MEXICO 


MEX 
key 
GS = Gateway Station (VHF- HF) 


* . Packet station wth weather 
neasuring capability 


NHC ~ National Hurricane Center, Miami 


Addendum - Sanple Véather Texts and Fornats 
Type 1:A Ship's Weather Report in Synoptic 
Code. 


ZCZC W8C656 

SMVD6 KWBC 080600 RTD 

BBXX 

VSBE9 08063 99236 70316 42308 60714 10242 20224 
40182 54000 84260 22233 00260 20101 3//// 4//// 


Explanation: Preanbl e contai ns addressee’ s 
call letters, ship's call letters, shore station's 
call letters, tine and date of nessage transmission. 


Five digit nunber groups indicate, by their 
position in the nessage sequence, date and tine of 
reading, latitude, longitude, sky cover, wnd direc- 
tion, wnd speed, tenperature in plus or mnus de- 
grees to the tenth of a degree, dewpoint, baronet- 
ric pressure, ship's directional heading and speed 
in knots, and wave hei ght. 


Note that the total weather report, including 
the heading, iS approxi nately 128 characters | ong, 
TAPR TNC default packet Iength. Equi val ent Jand- 
based weather observations can be sent from anateur 
veather stations in simlar fornat. 


Type 2: Sanple Airport Véather Report. 
SA 301300 


VRB SA 1251 60 SCT 280 - BKN7 213/51/45/1505/016 
TPA SA 1250 E50 BKN 250 OVC 10 207/55/47/1108/014 
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GA 


Nuc AN 
S 
py Nye 
0 GSH? 
Key West Va 


CARIBBEAN Ista. 


Note three letter abbreviations for indi cating 
city (i.e., Vero Beach, Tanpa), and abbrevi ati ons 
for cloud cover (i.e., Broken, Scattered, Overcast). 
Also included in infornation are day, tine, cloud 
cover elevation, configuration, tenperature, baro- 
netric pressure, dew point, wnd (in degrees and 
knots), precipitous accunul ation in inches, etc. 


Each line is a conplete veather report, and 
consists of only 49 characters including spaces. 


Type 3: Plain Text Reports for NOM Dstri bu- 
ti on. 
RCV 30939 14:54 01/30/85 


ZCZC MIACWFMIA 
WOUSOO KMIA 301500 


MARINE FORECAST FOR FLORIDA AND GEORGIA COASTAL 
WATERS 

NATIONAL WEATHER SERVICE MIAMI FL 

1025 AM EST WED J AN 30 1985 


SYNOPSIS 
HIGH PRESSURE RIDGE OFF THE GEORGIA AND FLORIDA 

ATLANTIC COAST WILL MOVE EASTWARD OVER THE NORTH 
PART AS THE SOUTH PART ROTATES THROUGH THE LOWER 
FLORIDA STRAITS 


NNNN 


Note the four Ns for standard teletype prin- 
ter shutdown. 


TCP/IP: A Proposal For Amsteur Packet Radio Levels 3 and 4 


Phil Karn, KA9Q 
Radio Amateur Satellite Corporation 
ABSTRACT 
This paper presents a case for basing Level 3 (the network layer) af Amateur Packet Radio on the “datagram” i 
further proposes that the DARPA protocals IP Protocol) and TCP (Transmission Cantrdl Protocol) be adopted 


intact as the standard Level 3 (Network) and Level 4 (Transport) protocols for Amateur Packer Radio. 


I will then provide an overview of TCP/IP, expl 


ain why it, as a data 


, IS more suitable far our needs than the 


gram protocol 
virtual-circuit protocol CCITT X.75, and show how it would be used above the AX.25 Level 2 protocol already in use. 


1. Dutagrams and Virteal Circuits 


A fundamental chzracteristic of ARPA (and several 
others, e.g., Xerox PUP [15]) protocols is the choice af 
the "datagram" as the ntal unit of communication 
Saeraicy al de Geageen aavoat on ta ciel aa: 
compari gram with its chief rival, 
the Nirtual Graut,” is needed. 

1.1 What is a Datagram? 

The word “datagram” is cained from the words “data” and 
“tdegram.” Like telegrams, datagrams are simple one-shot 
messages; each is self-contained in that it includes the full 
source and destination addresses, control information and 


user data. Each dat is tly 

dee nespock: All ierctation needed by. packer ewtich 
to route dat through the network is whdlly 
contained within each da No state need be 


maintained by a packet switch between datagrams. There 

are many analogies to this mode of operatio besides 

telegrams: mailing a letter, sending electronic nmil, or 

ee into the amateur radio National Traffic 
em. 


The network makes a “best effort” attempt to deliver each 
datagram. If datagram delivery is impossible (e.g., due to 
network congestim, buffer overflow ar an m or 
unreachatde destination address), a packet ane 
discard a dat Same datagram protocols (such as 
IP, to be descnced later) ire that an effort be made to 
notify the sender of the protien. 

Dat are never discarded lightly; however, there are 
usualy vayig degrees of een ae eae be 
expended before “giving up" @n a m. ; 
a greater effort at relia adivery incesesithe “cost in 
some sense) of sending the data or affects the user 
in some other way, eg., by easing throughput or 


increasi . IP, as discussed later, gives the sender 
the ability, if desired, to specify the 1 (i.e., the 
) of a datagram and to influence any tradeoffs 


delay, reliability and throughput that might exist 

in individual links and gateways within the netwar. 
In any event, a datagram user must always be prepared to 
cope with the occasional Ices, out-of-sequence delivery or 

lication af datagrams caused by network congestion or 
switch so link failure. Since Sane es require 
guaranteed service, a separate, protocol using 
end-to-end acknowledgements and retransmission of lost 
datagrams is generally used "on top" of the unguaranteed 
datagram service. 
1.2 And In The Other Corner... The Virtual Circuit 


As the name implies, “virtual arouit’ networks (hereafter 
abbreviated “VC networks") are oriented to provide the 
eppearance of a direct connection between a pair of users. 
The network sets up a fixed path though the network to 
the destination for the duration of the user’s connection. 
Because the may be shared by several users (i.e., the 
physical facilities are mot dedicated to a single user), the 
connection is “virtual.” 
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A special “call setup” packet propagates through the 
network, and each Fitch adds a “virtual call“ to am 
intemal table so that the data packets that follow may be 
correctly routed to their destinations. The best analogy to 
a VC network is the telephone system, although the 
analogy isn’t perfect because the bay fae network 
usually dedicates fixed physical resources (a wire pai 
channel on an RF carrier) to each call. 
aera in most VC networks is static; once it is 
established at setup time, all packets follow the same route 
to the destination. As long as all links and switches 
ee 
a properly delivered in sequence. ever, 
should a switch crash or a link fail, all virmal crauits 
using the affected switch ar link will be dropped and any 
data in transit will be lost. 


When the user is done with a virtual areuit, it is deared. 
This removes the information about the call from te 
memory of each packet switch alang the call’s path, 


1.3 Discession: Dategrams Ve. Virtual Circuits 


Many applications, such as remote terminal access to a 
computer, require a reliable, flow-contolled “stream 
connection" between two end A segs regardless af how 
this might be implemented in the bowels of the network. 
Therefore, the issue is NOT whether the user should be 
provided with a reliable end-to-end stream, but rather how 
It cught to be implemented. Should the concepe af a 
“virtual circuit" be confirsd to the endpants of a 
“connection” or should it permeate the design of the lower 
levels of the network? 

The choice has many implications for reliability, 
flexibility, ease of treisrneciation, efficiency, and 
adarzatility to varying user-level service requirements. 
The decision is a tradeoff, and aften the choice depends 
cn those characteristics considered most impcrtars. 
Neither approach is always superior. 

1.3.1 Ease of Imple:enation Datagram packet switches 
are considerably easier to implement than VC switches. 
Laoag oll Nome organ? and “call daring” packets 
means that all packets are alike as far as the switch is 
concemed. All that it has to do is select an ing link 
for the packet (typically based on a routing table is 
periodically updated from its neighbors) and send the 
packet on its way. If there is a serious problem with the 
packer, the switch is entitled to it; no intricate 
error-recovery procedures are needed. Sve the “what to 
Co when things go " $ection is the largest, most 
creas clin aogee ar aig pingianens epbore 
programming project, this results in an enormously easier 
goding jb. 


1.32 Dynamic Rowing As already mentimed, virmal 
arcuit networks establish fixed paths thr a network af 
packet switches and links. If a given link fails or beccmes 
overly congested, there is no easy way to reroute 
established virtual arcutts via altemate paths. 


Det 
individually routed without 
connections that might exist at a higher protocol level. 
This makes it possible to react on a per-packet basis to 
ange traffic conditions and network recorifigurations. 
Much of the work to date in non-amateur packet radio has 
been done in a mobile environment, and dynamic routing 
is essential here because of the constandy changing 
topology of the network. 


While it is certainly possible to make routing decisions 
based on link loading at circuit setup time in a virtual 
circuit network, this is less responsive to rapidly changing 
network conditions than the ability to route on a per- 
packet basis. 
1.3.3 Overhead This is the primary objection that is made 
against datagram protocols. Vit Circuit protocals 
require that camplere addresses be sent only at arcut 
setup time. Once the table entries are made in each 
switch along the path of a virtual Grouit, only the index 
into this table (referred to as a “virtual Grcwt murmber" 
need be part of each data packet for the switch to route it 
ly. ing on the size of the data fidds, the 
ger headers involved in datagram packets can involve 
considerable overhead. This is primanly tue with 
interactive terminal traffic that often consists af single 
character packets; it is much less of a factor when data 
fields are larger. 


On the face of it, virtual cirouit protocols seem to win the 


overhead argument hands down. However, there are 


must be first set up between the client and the server, the 
request made, the response received, and the virtual 
circuit tam down. This clearly results in more network 
traffic than if one-shot datagrams were used at the 
network level, avoiding the overhead of setting up a 
virtual Grcuit for such a short “connection.” 

To answer this objection, the X.25/X.75 protocd’s include 
an omtional "fast select" feature that allows user data to be 
sent in the same packet with a call request. Fast select is 
not, however, a substitute far datagrams. A virtual arcuit 
is still being established, althou 
reply packet (typically a INDICATE), with or 
without data, is still expected from the destination witin 
oe es by the network, and the data fieids 
contained in either packet are limited to 128 bytes; there is 
no fragmentation facility. This is considerably less general 
than a “irue” datagram facility. 

However, in the common situation where the application 
requires an end-to-end connection for a relatively long 
time, virtual circuit networks do require fewer tits to be 
transmitted than do datagram-based networks. In 
situations where the traffic consists primarily of single- 
character packets (e.g., interactive terminal access) and 
efficient use af slow and ive transmission facilities 
is af supreme i , the lower per-packet overhead 
of the virtual arcuit approach can be the overriding 
factor. [13] 

While amateur packet radio is currently severely 
constrained by obsolete Bell 202 modems and 1200 baud 
transmission, decicated RF modems operating at much 
highe (orders of magnitude) are now being 


igher speeds 
introduced. [16] Since these modems will not cost much 


for a short tme. A 
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more than those cumenily used (assuming a dedicated 
racic), this will almost completely mitigate the overhead 
argument. 
1.34 Reliability Because a datagram contains all 
information necessary to forward it anto its destination, 
no state has to be maintained in a datagram packet switch 
between pack:ts. ‘This makes dat networks much 
more resistare to real-world occurrences such as power 
itches, software failures and nosy visitars who push reset 
Tons. 


Since the reliatility requirements are less for a dat 
switch (sine it has no volatile table af virtual crautts to 
safeguard) such measures as battery backup can often be 
tesa with.! The only information that 1s typically lost 
withi gram packet switches during failures are 
ro! commectivity tables (assuming a distributed routing 
algorithm is used), but these can be quickly rebuilt from 
cne’s neighbors. Virtual crcuit switches, on the other 
hand, must maintain the information provided to it at 
Circuit setup time to route successfully each cata packet of 
a virtual commection. In general, this information cannot 
be rebuilt from one’s neighbors, and the end user must 
oe ee circuit and recover from arty lost 
a. 

To achieve maximum reliability against internal network 
protlens, both datagram virtual circuit networks 
Tequire a higher-level end-to-end “transport” protocd. A 
ce ee ee that might 
cccur in the network (last, reordered or duplicated packets 
in a datagram network, or dropped virtual arcuts in a 
virtual circuit network). The transport protocol used atop 
the ARPA data ad, IP, when reliable stream 
communication 1s desired is called TCP (Transmission 
Control Protocol). 


A major advantage of an end-to-end protocal such as TCP 
is that it provides ion against data corruption (as 
well as loss) aiong the ENTIRE network path Link level 
error detecting codes (such as the 16-bit CRC in AX25) 
provect only against errors on transimsssion links. Without 
end-to-end lon, a user is still vulnerable to data 


corruption can occur in a packet switch between the 
recepoon at ee cage bones retransmission with a freshly 
regenerated CRC. The probability of this occurring in a 


single packet switch may be acceptably small, but in a 
large network composed primarily of inexpensive 
micrccomputers without memory error detection, errors 
are inevitable. 

Many virtual-circuit daim that their networks 
provide “reliable” VC service with less complexity than 
datagram networks because they do not "need" an 
elaborate end-to-end sa Spel ey However, many 
X75 networks provide N to-end transport protocal 
at all, and as a result the user is still vuinerable to failures 
within the network that can lose infomation ar drop 
connections. In practice, this hapnens aften enough to be 
annoying. With an end-to-end transport protocol on a VC 
network, the reliability can oach that of, say, a 
TCP/IP network, but now Bir implementation 
complexity is er because the at 
falgcle levels. Tr 


1.3.5 Grades of Service VC networks are impliatly based 
on the assumption that all applications require a reliable, 
flow controlled stream “connection.” However, there are 
several real-time’ applications that either do not require 


1. Most ilures are brief, and if the switc 
MS eae ey Sher tara a ee eae 
Bea ClcG Gy bes inact) “et” oo a 
transfer’, not a connection. oe 

2. “Real time” 


being sieerieed sual Gay 5 te aa 


this of service or cannot tolerate any overhead 
intr by it. 
The best e of an application in this categary is 
packet voice. le conversing on a telephone channel 
are sensitive to long transmission delays, espeaally if they 
are irregular, In contrast to data transmission, however, 
human s can tolerate a certain amount of last or 
data because of its great redundancy, and 
“perfect” reliability may be sacrificed to reduce delay. 
Other es af real-time applications might indude 
television (“digital SSTV") and satellite tdemetry. In each 
case, there is litte point in retransmitting lost “dd” data 
because "new" information will arrive shortly to take its 
ce. For example, real time satellite telemetry gai 
ittle from retransmission of lost frames; the user might as 
well wait for updated infanmation (and then interpolate 
the missing values) instead of falling behind by trying to 
recover data that is already out of date. If a somewhat 
saad degree of reliability 5 Seger the cost af 
" reception is too hi satellite might simp! 
ee Gat Gane xa weera dey w deere te 
chances of successful reception, or use other more 
complex forms of forward eror correction (FEC). 


In a datagram network, these kinds of application-specific 
tradeoffs are easy. For example, conird hits in each 
datagram might select the use af ee 
dgements. In a VC network, however, 
ications get hopby-hop acknowledgments whether 
need them or not. T applications might place 
different levels of 1 on ditferert messages cf 
eme vs routine traffic) but because VC netwaor. 
typicaily traffic on established virtual arcuits cn a 
first-come, first-served basis this is difficult to do. 
While it may be a while before amateur packet radio 
networks have the capacity to handle packet vaice at a 
practical level, it would be unwise and shortsighted to 
adopt a protocol that would effectively preclude it from 
our network. Baan cles pe a 
of resources that could occur if a common network co 
satisfy the needs of arnateur data and vaice users. 


1.3.6 Broadcasting Virtual crouits are inherently point- 
to-point and usually full-duplex, and thus they do not lend 
themselves easily to the notion of a “broadcast” sa 
Sending the same information to N receivers requires 

N virtual circuits be created, one to each receiver, and 
that N copies af the data be transmitted. This is clearly 
wasteful when the underlying media permits broadcasting 
(such as Ethemet [10] or radio), and datagrams are a 
much more natural solution. 

Given that reliable delivery to every receiver in a 
broadcast environment is much more expensive than 
reliable delivery to a single destination, it 1s even more 


to-pa 

mechanism appropriate for the specific application woul 
then be implemented an top af basic 
Other situations where broadcast mechanisms are useful 
indude the construction and exchange of routing 
information, and in distributed processing to manage a 
collection of systems providing a set of services. 

As with dynamic routing, datagrams do not, in 
themselves, scive every problem involved in broadcasting, 
Bi hy Ont pet one SO oe 
networks. 


Sealing, seeet, Peg vesned curendy. 
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2. What i TCP/IP? 


The ARPA Transmission Control Protocol (TCP) Os 
the ARPA Inemet Protocol (IP) [1] are part of a larger 
collection of protocols that enjoy widespread and rapidly 
growing usage within numerous commercial, research and 
military computer networks. 

Before delving into the internals af these two protocols, it 
is necessary to understand the needs of ther developers 
and environment where they were designed. 

The ARPA research community that designed TCP/IP is a 
user (as opposed to a vendor) of hardware and 
communications facilities, and this a major impact on 
its design. [9] A basic requirement was the interconnection 
i amcor Lae et nara using the widest 
possible variety af link-level networking hardware and 
protocds. This was important for two reasons: first, 
much of the hardware already existed and couldn't be 
thrown awzy. Second, the user community wanted a 
“hardware 1 emt’ protod to guard against 
becoming “locked in" to any ane vendor’s products. This 
is in contrast to a vendor's usual incentive to establish 
standards that favor the use of ames’ own products over 
those af the carpetitian 

It was found that the networks in use vary radically in 
their characteristics. Some support the pee of 
“connections”; others only ide unguaranteed delivery. 
All vary widely in reliahlity, transmission s and 
addressing formats. The datagram was the only feaste 
choice as the “common unt” of transmission that could be 
“encapsulated” on each of these heterogeneous networks. 


Cther ARPA requirements included robustness in the face 
of intemal network failures and reconfigurations, 
provisions for precedence, dlass-of-service security 
Classification, and optional user specified routing. Because 
mo exisdn Is satisfied these requirements 
(including X.25/X.75), it was necessary to design 
a new set of protocais. . 
The widespread acce of TCP/IP outside the military 
community that originally s its design shows its 
success in meeting the of a wide variety of users, 
not just those of the military. The latest available figures 
show that address assignments have been made to a total 
of over 3,000 distinct networks af varying sizes. About 
half of this total represent Defense Government- 
sponsored research izations that are interconnected 
to form the ARPA. Intemet, wile the rest are 
independent private (mostiy commercial) networks. While 
the exact total number of hosts that s the Internet 
protocals is unknown, the ARPA et host file 
currently contains 1,146 hosts, ranging from IEM PCs to 
large timesharing systems. 

activities within the Intemational Standards 
Organization (ISO) now include the design of a protocal 
based on TCP/IP (TP4), although the T seems to 
remain adamantly opposed to this type of protocol. 
In the following sections, I will discuss the major features 
of the ARPA IP and TCP protocds. In gener, the 
statements made earlier about datagram protocals apply to 
TCP/IP. In addition I will pa out some differences 
between TCP/IP and X.25/K.75 that are specific to those 
protocols and not necessarily related to the 
datagram/Virtual circut selection. 
2.1 The Internet Pretoce! (IP) 


The Intemet Protocol (IP) occupies level 3, the network 
layer, in the ARPA Sects “suite.” As its name implies, 
IP is the “universal language" of the network, it is the 
“Esperanto” of a larger network built up through the 
interconnection of many smaller, heterogeneous networks. 


IP is a dat protocol that makes minimal assumptions 
por te hobs it es IP headers contain only that 
information necessary to ide network functions such 
as addressing, classes service, precedence, etc. In 
particular, there are no end-to-end features such as 
guaranteed delivery, flow control, sequenang, or other 
services commonly found in virtual arowt provsodls. Asa 
result, IP is simple and easy to implement on a wide 
variety of networks, including many that cannot directly 
support virtual circuits. late relay points 
(hereafter called "gateways") only need implement IP in 
addition to whatever link level protocols are being used; 
any end-to-end functions remain the domain of higher 
level protocols in the user systems. 

Te a oe ee ee 
Since many (most?) networks cannot handle such large 
packets, IP provides a feature called fragmentation. Thus 
allows a gateway faced with a datagram that won't “fir 
into a given link level protocal to split it into several 
smaller datagrams that will. Each "fragment" behaves 
like a separate datagram in its owm nght and will 
propagare independently through the network. Only when 
they arrive at their destination will they be “reassembled” 
into the original, larger datagram and passed to the next 
layer protocal. As we will see later, dus is an important 
7 aul at 


Each IP datagram contains a “Time To Live" (TTL) fidd 
that is decremented as the datagram propagates through 
the network. If the TTL reaches zero before the dat 
is delivered, it is destroyed. Of course, the TTL fied is 
set to a large enough value so that the datagram is likely 
to reach its destination; however, if a transient routing 
loop occurs in the network the datagram will nov circulate 
indefimntely. ae. Z Pia Lae me] at aia bbe 
disappears , eld protects higher orocals 
Sy) ctiiching the nenilin ifeva when they met 
Ce eee The 
feature provides backup protection against buffer 
deadlock by ensurin, ae gorpe Spore tae geet in the 
network indefimtely. A cal (although eaieetd 
impractical) analogy might be the plaang af a time bc 
in each car entering New York Gty. Normally, the cars 
leave the city in plenty of time, and there are few (cr mo) 
explosions. If gridlock occurs, however, even in the 
absence of any cther actions taken the problem is 
guaranteed to go away eventually by itself! 


Several features af IP are not used frequently enough to 
justify their inclusion in every datagram These "IP 
ea are listed in [2], but the most interesting ones 


1. Source routing. Normally, gateways do thar own 
routing, but two forms of user ("source") specified 
routing are available. One, "strict source routing” 
specifies the exact path that must be used by 

gram; if this path is invalid, the datagram is 
discarded and a failure repart is sent to the user. 
The other form, “locse source routing” allows the 
user to anly partially specify the route; the gateways 
are free to determine paths between each user- 
specified point. 

2. The “recard route” option asks the gateways to route 
the datagram automatically, bur to record in te 
datagram the path used. 

3, Related to the “record route” option is the “Internet 
Timestamp" option. This option requests that each 
gateway record the time when it processed the 
datagram. 

Most datagrams are sent without of these options. 
However, they are extremely useful for special functions 
such as testing ar collecting statistics about specific paths 
within the network. It should also be panted our that 
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%.25/X%.75 provides none af these features. If they are 
considered necessary for amateur packer radio they would 
have to be added to those protocols. 


A special "“protocal” called ICMP (Interr:t Contrd 
Message Protocol) is considered an integral part of IP. 
ICMP is simply a standard way for an IP gateway to send 
@ report back to the onginator of a datagram when same 
unrecoverable error occurs. Gateways are required to 
generate IOMP messages whenever a data must be 
dronped for any reason, with the sole exception that ICMP 
messages are never generated about other ICMP messages 
(to avoid endless loops). ICMP messages report such 
error situations as invalid IP header formats, unreachable 
destinations, buffer congesuon, umeto-live fields 
expiring, etc. 
Other ICMP messages are of a more advisory nature. 
The “Redirect” I message is used to noufy a host's 
routing algorithm that an altemate gateway is a more 
path to a given destnation. There is also an 
ICMP “echo/echo reply” message pair that allows a host to 
monitor network perfarmance by “pinging” echo requests 
off selected destinations, perhaps using specified routes. 
2.3 The Transmission Central Pretece! (TCP) 


TCP is the standard ARPA Level 4 (Transport) protocal. 
TCP, and nx IP, provides optional eae eal “virtual 
circuit" service to applications that ire it. Consistent 
with the concept at pasar canta’, TCP resides only 
Be ee ese ace 
computers containing « ication programs) and nt in 
the intermediate Seewaye TCP oie the (potennally) 
unreliable service provided by IP and provides a reliable 
Stream Therefore it must uence dat that have 
been delivered out af sequence oy the network, detect and 
discard duplicate datagrams generated by the neowork, 
and request retransmissions when data is lost altogether. 
While internal details of TCP are beyond the scope af dus 
paper (see [3] for the formal specification of TCP), several 
of its key features can be mentioned here. 


character packets; TCP " " (e, the datagrams 
that it sends by way of IP) can be of any length up to a 
limit negotiated by the “maximum ent size” 


option. However, in omtrat to X25, receiver 
acknowl edgments show exacily how many bytes of buffer 
space (the window’) are available. 


In X.25 level 3, ence mumbers refer to “packets” that 
could be af any size fran 1 wt, say, 256 bytes. The 
receiver’s “vocabulary” for flow control is limited t two 

ases: “receiver ready (RR)" and “receiver no ready 
RNR)." How MUCH the receiver is actually ready to 
accept when it says "RR" must be agreed on in advance 
and speafied to the protocds. The maximum is 7 with 
standard sequence numbering, wtzle a typical value is 2 
packets. This means that the receiver cannot confidently 
indicate that it is ready to receive any data at all unless it 
has at least enough buffer space for two full-size (256 
byte) packets. Ag the other end af the circuit, the sender 


packets, even if each af these pa 
ae character. This obviously limits efficient buffer 
lization, and can severely limit throughput as well. 


2.3 AX.25 and Digipcaters: A Peor Man‘s TCP/IP? 


Those who have followed the development af AX 25 
Level 2, particularly the digipeater feature, may have 
ee a ee eae 
done under TCP/IP. 

What we call "“AX.25 Level 2” is, in fact, composed of 
two distinct “sub-layers." The of these two sub- 
protocas is the familiar connecnon-oriented, end-to-end 


byte stream protocal essentially identical to X25 LAPB. 
However, the essential changes that were made to X25 
LAPB to form what is now known as AX.25 Level 2 


When AX.25 is used directly between oe (i.e., no 
a arpa are used) it looks reasonably like an ordi 

ink level l. However, when digipeaters are 3 
the virtual-circuit level of AX.25 (the transmissim of 
connect requests, Sequence numbers, etc) is “promoted” to 
serve as an endtoend wungorn analogous to 
TCP. The digipeater is, in fact, nothing more than a 
datagran bas | isp switch, although it is very simple 
because it can’t do routing. 

Nor would automatic routing by digipeaters be desirable, 
since LAPB, which was intended solely as a link level 


dl, does not make a very transport r=otocal. 

example, it is totally Siac by once that arrive 
out af order or duplicated, events that inevitably occur 
occasionally in datagram networks with automatic jars 
mechanisms, but not on the point-to-point links for whi 
it was designed. There are also situations where 
information can be lost in LAPB oer, Oar by 
higher level protocais; this is unacceptable behavior by a 
transport protocal, the user’s last defense against data 
Corruption. 
However, AX.25 withoa digipeaters is entirely suitable as 
a link level mechanism for relaying IP datagrams from 
ane packet switch to another, and it can play an important 
synergetic role here. A major problem with our existing 
ad-hoc digipeater networks is the lack of hop-by-hop 
acknowledgements. If a packet in transit down a chain af 
digipeaters is lost for any reason, the transmission must be 
restarted back at the source. Even more wasteful is the 
loss of an acknowledgement in transit, as this requires the 
retransmission of the data being acknowledged as well as 
the retransmission af the acknowl . If the 
probability of successful transfer between adjacent 
digipeaters were high enough, end-to-end retransmission 
would be rare and would not be much of a performance 
problem. However, marly problems, including the 
‘hidden terminal problem,"” poor RF links and 
overloading, cause significant numbers of packets to be 
lost in real digipeater networks. If IP da were to 
be sent in "raw" HDLC frames, a long multihop TCP/IP 
connection would suffer as much from this problem as a 
long multihop AX.25 connection. However, if an AX.25 
link existed 
regular acknowledgme 


Would instead be handled by TCP, a much more robust 
al specifically intended for this job. 
ransmissions by would be quite rare and wold 

occur only when a link failed or became congested within 

the network. 


consurnmating such a marriage. Much of it is modeled on 


2 ie, ates acl rien. eee ca 
poe Sin urea key Mee 
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an existing standard for the transmission of IP data 
over Public Data Networks using the X.25 interface. 


S. Sending IP Datugrams on AX.25 Links 

IP was desi to be easily “enveloped” in a wide variety 

of link level protocols, and the AX.25 link level is easily 

capable of supporting it. However, a standard must be 

established, ete items capes be addressed. A 
oposed stan is ented ; &@ summary is 

Srmanedin Appia A 

3.1 Pretecel ID 


The Layer 3 Protocol ID byte immediately follows the 
contra’ field in AX.25 Level 2. Until version 2.0 af 
AX.25, only a single value had been defined: hex Fi, 
ee ", i.e., send the packet directly to the 
inal. For AX.25 Versio 2.0, the Protocol ID byte 
hex OC has been delined to mean “Internet Protocal.” 
3.3 Service Mappings 
Two of frames (I and UO!) in AX25 
Girton Hframes are sent’ using the full’ LAPS 
(connection-oriented) facility, while Ul-frames allow 
access to the underlying datagram sublayer af AX.25 and 
do not provide guaranteed delivery. How should the 
“class of service” bits in the IP header conti the selection 
of the frame type used to send the datagram? 


Two “class-of-service” bits are relevant, “low delay” and 
"reliability." A reasonable mapping would seem to be the 
following: If the “low delay” bit is set (and the others are 
not), then send the datagram in a UI frame (1.e., do not 
use per-hop acknowledgements). On the other hand, if 
the “reliability” bit is set, then use I frames (i.e., use the 
per-hop acknowledgments af AX.25 level 2 to increase the 
chances of the datagram being successfully transferred to 
the next gateway). If neither (ar both) af these bits are 
set, then it is up to the individual gateway whether to use 
I or Ul frames. This choice may be based on local 
= €.g., experience in the reliability af a given RF 


Tr is not dear how the “throughput” bt should be 
interpreted, so for the time being it should be ignored. In 
the ARPA Intemet, it is gateways that must 
ceestia ume and a high toughpu (tut large 
terrestri a t 

satellite channel in reaching a given destination. : 
3.3 Fragacautstion 


The AX.25 Level 2 document specifies that the maximum 
size of an I-field shall be 256 octets. This means that an 


IP datagram that is larger than 256 octets must be split 
into several using IP’s fragmentation faality. Since hosts 
on the ARP 


often send 512 byte datagrams (to 
reduce header overhead) dus facility must be i d 
if our network is to interconnect with navAX.25 based 
sites. 

3.4 Address Rseilation 


An IP address is a fixed-size 32 hit field, too small to 
contain an amateur callsign. Widening tis field is out of 
the ion since it would no longer be IP (remember 


c relegated to my 
Routitg Issues 1 


Therefore, there must be same way to map between the 
addresses used at the IP level and the addresses (call 
signs) used at the AX.25 link level. Fortunately, an 
almost identical problem has already been salved in the 
ARPA community, that of sending IP datagrams over the 
Ethemet local area network. 


Ethernet link level addresses are 6 bytes lang. Unique 
addresses are opaaied by the manufacturer into a 
ROM an each met controler, and they cannot be 
easily ed by the user. After several unsatisf 
ad-hoc kKludges, a sdlution ed by David Plummer af 
MIT was widely adopted, and it has worked well. 
Piummer’s Address Resolution Protocal, or “ARP” [6] 
(not to be confused with “ARPA") has been widely 
adopted and is general enough to work on cther 
broadcast-type local area networks besides Ethernet (such 
2s packet radio). 


ARP works as follows. Whenever a station needs to 
determine the link layer address (e.g., the Ethernet 6-byte 
address or the AX.25 Level 2 call sign and sub-statian ID) 
scab pee to a given 32 tat IP address, it broadcasts a 
spedal “ARP Request” packet on the channel. The station 
with the requested address res with an "ARP Reply" 
carat containing the desired link level address. 

aturally, to avoid having to invoke ARP for every 
datagram each IP station maintains a cache table af IP to 
link address correspondences. This table does not have to 
be large since it will contain only those stations that are 
“neighbors,” i.e., stations to which packets can be directly 
sent using level 2. Packets addressed to more distant sites 
will be sent first to a gateway, and it is only the gateway 


wise link layer address is needed. Entries in tre ARP 
table are , occasionally purged, and replaced with the 
reply to a ARP request to allow far the possibility of 


network reconfiguration (i.e., stations changing thar IP 
addresses 


) 

The beauty of ARP is that it works automacail) and 
trans ly. The IP layer need not be conce with 
linkklayer addresses, and there is no need to maintain 
manually a table of IP and link level addresses. In 
practice, it 1S even possible to swap Ethemet boards (and 
their addresses) between computers without any adverse 
consequences. 
ARPA has already assi an ARP “hardware type" 
value af 3 to w028 tel De falas and Ps 
oe ern Identifier 
3.5 Addressing and Routing 

facing any higher level Amateur 


This a major challenge 
Packet Radio promcd, vimua Grout or daagram Since 
this paper 


the purpose is to argue the case for TCP/IP, 
I have devoted a companion , “Addressing and 
Routing Issues in Amateur Packet io," to this topic as 


these issues apply equally to an IP or a X75 network I 
will simply mention here that ARPA "Class A” network 


mumber 44 has already esigirae' acy rani Feo 
radio through the foresight of Hank Magnusk, 
IP addresses are always 32 bits wide; addresses within the 
ARPA assignment would contain 44 (decimal) in the first 
8 bits of the address, and the assignment of die remaining 
24 bits is left up to us. This provides the ability to 
address 16,777,216 individual stations. 


4. Conctesions 


It is difficult to summarize in just a few words what has 
been argued about at length by so many people, only a 
iny fraction of whom are involved in amateur packet 

io. Nevertheless, TCP/IP’s proven flembiity and 
adaptability makes it an extremely attractive candidate far 
our needs. It already provides virtually every function we 
need in an amateur packet network and can be adopted 
exactly as-is, keeping open the A ened of direct 
intercaxmection with non- amateur TCP/IP networks. 
TCP/IP is ideal for amateur radio, a heterogeneous 
environment where stations come and go, propagation 
paths change, satellites rise and set, and users experiment 
with new applications and transmission schemes 
unforeseen at present. 


In contrast, X25 and X75 are much mere limited 
protocols designed for a homogeneous common carrier 
eivironment with static network topologies, reliable 
nodes, point-to-point transmission lines, and a limited set 
af user services. Many ad-hoc changes would be required 
if they were to be used on amateur packet radio, creating 
new, umique and incompatible protocds. Interconnection 
with nor-amateur networks would require protocd 
conversion gateways, a totally unnecessary complication. 
Virtually all non-arnateur packet radio systems use TCP/IP 
(and none whatsoever use X75, to my knowledge). 
Furthermore, the fact thet amateurs are already using a 
protocol much like TCP/IP (i.e., AX.25 with digipeaters) 
gives strong support to the convenience, flexibility and 
simplicity of this approach. If we adopt TCP/IP, we will 
be able to tap the enormous amount of experience that has 
been gained (and made public) with it over its 10+ year 
evolution. If instead we adapt X.75 and the higher layers 
of X25, we will be forced to salve (ar endure) many af 
its deficiencies in 2n ad-hoc, unique and time consuming 
way. 
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6. Appendix A 


any datagram ; 
ar neang thee256 byte fame sige limit is a 
subject for future study. 


i ee error rates; however, this should be done as 
a last resort. 


3. The choice between the use of an I or a U! frame 
for the transmission of a dat is made by 
examination of the “Class af Service" bits in the IP 
I j . De e 7 oqe ° 


between I and UI frames besed m lal 
considerations. 

The interpretation af the “Throughput” bit is a 
subject for future study; in the meantime it should 
be ignored. 


4. Buffer space permitting, each Level ‘Two 
implementation should be able to accept and process 
Ul frames containing IP datagrams whenever they 
are received, whether or not a regular Level Two 
comection exists with the sending station or any 
other station. 


reliability bit set, ar they may be continuously 
cannes Se on by 
the stations concerned. an AX.25 el Two 
comiection is to be taken down, each station should 
make every effort possible to ensure that any 


Outstanding dat semt via I frames (i.e., 
datagrams with “reliability” bit set) have been 
sent and acknowledged before going into te 
disconnected state. 


anented ities to itations. 
Such 


1 It may be See ie tO usé an i eae 
ais 2 Tact Ph a aoe : 
ny Ww te gu the associat 
Be Pgh gage fone nS ay 
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6. There is no effort to muintan Level Two 
connections carresponding to any end-to-end virtual 
Circuits that may exist at higher protocd levels. 


6.2 Address Recslatica Pretecel 


Whenever a station needs to determine the AX.25 Level 
Two address (i.e., the amateur radio callsign) of another 
pee ee ee ae et ee 
address, it shall use the A Address Resolution 
Protocol (ARP) as described in RFC &26. The value af 
the “hardware type" field in an ARP packet has been 
Re en ee ‘Amateur Radio 


Esch ARP broadcast and reply packet is sent in a e 
UI frame immediately after the AX.25 Level 3 Protocal 
ID byte, which is set to CD hex denoting ADDRESS 
The contents cf the AX.25 Level Two destination field to 
be used for all broadcast packets (including ARP) shall be 
"QST" with SSID 0. 


Addressing and Routing Issues in Amateur Packet Radio 
Phil Karn, KA9Q 
Radio Amateur Sarellice Corporation 


ABSTRACT 


As amateur packet radio evolves from scattered, ad-hoc collections af local area digipeaters into a 
interconnected network, several issues related to naming, acdressing and routing will have to be faced 
Routing, in partiadar, has long been a fertile research area in computer 
els - however, I believe that they can at least be stated, and that certain decisions can be 
imentation with various solutions. In particular, the problem of address assignment is discussed 
with particular emphasis on making the routing protiem easier. 


answers to many af 
made early to ease 


1. Intredection: Term izelegy 


I will begin by defining several i amr terms. A link is 

wey trocerisiion line fadio channel or the ke capable of 

carrying a packet directly between two paints. Nodes are 

the points af links, A node may generate packets for 

other nodes, consume packets addressed to itself, or act as 

Sl ae 
er nodes. 


Reference [1] gives a concise but effective definiton af 
three more concepes: "In simole terms, a mane tells what 
an object is; an address tells where it is; and a rage tells 
how to get there." 

To elaborate: 


1. A name is an arbitrary string of characters, chosen 
for human convenience, to designate a partialar 
person, node or service. Examples indude people's 
names and the network names given to computers. 
Ammteur radio callsigns might also qualify, al 
many may dispute their convemence! 

2. An addvss is a nurnber corresponding to a name, 
significant to a communications network. It is 
Se eee 

ed format. es include telephme 
numbers (10 decimal digits in North America), 
Internet Protocol addresses (32 bits) and, of course, 
postal addresses. 


3. A rowe is the path over which a specified address 
may be reached from a given pou within a 
network. 

Some communication systems blur the distinction between 
these cmcepts. For example, an aid-time telephone 
system with a Inman operator might accee a a 
persan’s name or a telephone number in placing a call. A 
courier might accept a route (“go to the turd (red) house 
on the right after making a left tum at the light”) in place 
of an ackiress. However, machines demand short, precise 
identifiers that ars often not convenient for humans to 
remember, so translation from names to addresses then to 
routes must be provided. Telephone books and directory 
assistance systems provide translation between narnes and 
telephone numbers, while maps provide the information 
necessary to find a route to a given street address. 

While names are ally arbitrary (except that they 

must be unique, at least in the context in which they are 

used), addresses may or may not imply something about 
physical location to facilitate route selection. For 

e, telephone numbers in North America are 
assigned by a multi-level location-dependent hierarchy; the 
first level is the 3-digit area code and the second level is 
the 3-digit central ria 
same telephone mumber; you must get a new cne that 
reflects your new location. You are allowed to keep your 


name, however; the telephone company grants you this 
ane concession! 


e, aufarmitic, and 
overcome. 


networking. I make no daim to knowing the 


Because of the arbitrary nature of names, full-hown 
database systerrs are generally required to convert names 
into addresses. The telephone network provides name-to- 
address mapping telephone books and directory 
assistance bureaus. Computer necworks may use either or 
boih of these techniques, eg., a directory may be 
roaintained locally in each user system, or a central site 
may be set up as a “name server.” 


3 Naming Iu Computer Ndworks 

Deo eee tees Ne oe eee 
selected name. For small networks, a single central 
cleari e for name assignments is practical. For large 
networks, however, hierarchical allocation is the most 
practical 

The ARPA Internet has grown rapidly over the past 5 
years, and its central name registry is showing 
considerable signs of strain. To answer chs protiem, the 
ARPA Internet will be evalving from a single, giobally 
administered name space to a hierarchical “domain-based” 
system {12,13}. In the domain system, a name may 
consist of several words separated by _ periods: 
FOOCBAR ARPA, meaning host name “FOOBAR* under 
denain “ARPA.” The same system might be more fully 


named as FOOBAR.MIT.ARPA, distinguishing it from 
oi Meg pe cpanel a Dery ag "in 
locations within the ARPA “top-level domain.” 


Partially specified domains are interpreted based on the 
location in the hierarchy where the name is encountered, 
and “nearby” (in a huerarchical sense) hosts naught be 
named without any domain names at all. is is 
analogous to the way people refer to others by their first 
names (¢.g., within a family or work group), but would 
ive full names when referring to someone on the 
ourside." 

The ARPA liternet has only begun its conversion to the 
domain system, and several detals need to be worked out. 
Within amateur radio, the easiest naming convention 
walls eeaety Re te Oe ee ee 
already unique. A domain name d be allocated (e.g., 
AMPRNET) so Abela the ina ecards os seo its 
conversion our callsign-names simply me, €.g., 
"KASQ. AMPRNET” outside our network . 


3. The Reuting Pretian 


Qnce the network is given an address, it must select a 
route to reach it. Again, this may be done centrally, in a 
network manager that keeps track of the entire network 
(e.g., [4]), or it may be done in a distributed 

ion by local routing algorithms that operate from 
partial, lecally constructed views af the network state and 
topdogy (ARPANET, many others [2,5,8)). 


$3.1 Centralised Resting 


Centralized routers [5] have the advantage that a 
complete, coherent “picture” of the entire network can be 
maintained at a single point. Decisions can be based m 


Communication overhead is involved in the calection of 
status reports from and the dissemination of routing 
decisions to the individual packet switches. The reliability 
of the communication paths to the central router (and that 
of the central site itself) is critical to the entire network. 


The communication overhead with a centralized dea 
more practical in a virtual circuit network, since routing 
Gone only at circuit setup time. Sudh'an approach i 
harder in datagram networks such as those 

ARPA IP because routing mst be dane on a per-packet 
basis (although one might “cache” routing information at 
the switches to minimize overhead). 

3.2 Distribated Routing 

An altemative is distrilaaed rowing, where each switch 
makes its own deaisians based an a “local view" of 


the network. Switches usually exchange information with 
each other, oe ee 


thus @ composite “snapshot” of the network. 
algorithms work well in datagram environments 
have other es, such as i flexibility 


sel agente distributed routing algorithms are 

ie y in datagram based networks such as 
EP AEPA emet, and I recommend its use in amateur 
packet radio. In the remainder of tus paper, I will assume 
the use of distributed routing. 


4. Routing Implications for Addressing 


A cket switched network consists af a collection of 
Seay ofa fos anak ints. 


direcdy with “tH other nodes (e.g., Ethemet, ccs 

spaced terrestrial packet radio nodes or nodes 

satellite channel) routing becomes trivial; packets can 

oe Similarly, if the node is 
a “stub” (i.e., it cm only communicate with one other 

mide) there is obviously anly a single possible chaice. 


In the general case, however, network nodes are 
coly percaly inercmnccred wi links and a packet must 
Qiten be sent first to the neighbor which can best relay it 
onward to the destination. 


One sdiution that works well in small networks (such as 
the ARPANET) is for each node to maintain a list of all 
other nodes in the network, lving the te 
—s to which packets for each destination si be 

(It is uns ed at the moment how these entries 
ie dae nied As the network grows, sagt N ae 
node’s routing table will grow as well and the tocal 


amount af required at all nodes for routing tables 
will grow as the of the number of nodes. arly, 
much memory could be saved if the list entries for nodes 


sharing the same “next hop" could samehow be 
condensed. This is possible if the addresses, instead of 
being arbitrary numbers, are related to the location af the 
node within the topalogy af the network. 


At a node far removed from a given set of destinations, it 
is likely that the same neighbor would be used to reach 
pal ar atl atedlaastg con a If their addresses 

are "similar," in some sense, then it might be possible to 
“condense” these addresses into a single routing table 
eniry. 


S. Address Assigument Within IP 


Bearing in mind the desirability af somehow encoding the 
ee ee I will now 
tum to c em SS ass Within 
the ARPA Inbernet Brotocd,, IP ae 

An IP address field is 32 bits wide. IP addresses are 
further subdivided, Fay y for acmninistrative reasons, 
into three classes: B and C The major difference 
between these three classes is the number of hits within 
this 32 bit fidd that may be assi by the network 
Sees ae bony een ye This 
procedure is network is ever to 
Gomi withthe esting ARPA lene, sxe two 
sites might pick the same IP address unless there was 
some form of central coordination. 


Thanks to the opi cf Hark Magmski, KA6M, 
ARPA has assi A network number to amateur 
packet radio. bis is @ very valuable commodity, in that 
it fixes only the first byte of our addresses (to be decimal 
eS ee ee 
own use while ioe a 
interconnection with the PEARPA with te the 
aN 24 bits, we can address 16,777,216 nodes, 

easily enough to give eve amateur in the world his or 
her oat TP akires if we ocate them efficently. 


ee ees eee 
ee ee ee ee 


pleasing, are inefficent 

their space over the poles, places with remarkably 
few amateurs. 

Clearly a more efficient scheme is needed; one possibility 
is the binary tree. One way to illustrate this form af 
et re, eta ee ae ee 
Experien Players of this know that the best 


strategy consists of asking Stns for which “yes” and 
yea ‘be eaepy ote 


exit wraud be reasonable to essign the frst Uit of 
24lit address subfield to mean “USnarUS.” Within the 
United States, ce might determine that half of the 
packeteers are east of the Mississippi Se ee ae 
west, and so forth. Eventually, you reach a single “RF 
community” and you would assign the remaining address 
bits sequentially to the individual amateurs in that area.! 
etic ple plicit advantage of such a scheme is that the 
ay of assigning addresses can be delegated to a naples 
anions. An international organization (e.g., the 
TARO) woul would define only enough apt bits to uniquely 
designate each region or country in the world. Nan 
Grganizations within countries would then i 
addinonal fits denoting regions within the country based 
On national concems (i.¢., the ARRL in the United States 
might handle this job based on American geopolitical 
boundaries). Other countries would have maximum 
freedorn to devise their own national level se asd 
plans which might take into account unique nati 


* oplar CPM ropams "SQ ag 
PINSCUEEZE = an 


cri with =a “characters 
i accandin the relative character 
iOutions in the 
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jrements oc conditions. Ar the lowest level, an 
individual packet station would oniy have to contact his 
local packet radio coordinating body for a specific address 
assignment, and these “front line" orgamizatioss would 
have maximun flexibility in devising an allocation scheme 
suitable for the local environment. Individual assignments 
would then be forwarded back up the ongazuzational 
hierarchy (or maintained in a “well known" directory 
server) so that the network as a whole nay have 
convemient access. 


Since node addresses in a given area have commom 
fixes, it is likely that a distant node would an! have to 
a single routing table entry for a large collection af 

. For example, a packet switch in New York would 
only have to maintain the information that all packets to 

west af the Mississippi are sent to node 
“condensing” half af the packet nodes in the USA into a 
single routing table entry in the New York switd. 

1 cal ie pilates Bind. elie 
assignments, ing table entries may consist af variable 
length pre s._ These profes migit vary fram 0 Ws 
long (correspanding to a “wild card" or “default” routi 
entry to be used on the end af a stub, for example 
to a full 32 bits when used to describe an special entry for 
a specific address. The latter case would be useful to 
handle special cases, such as point-to-pcant commections via 
satellite, ar a node whose entry cannot be condensed with 
any ocher existing entry. 


larger than average if a node were located near a 
boundary in the ss scheme, e.g., the US/Canadian 
border. However, that such a scheme would 
reduce the A size of routing tables in the 


network, More work on this problem is needed, 
particularly a comparative estimate of the routing table 
sizes and growth rates for a variety of address boundaries 
and population distributions. 

It should be noted here that the issue of hierarchical 
address assignment is ing much interest in the ARPA 
community. Currently, addresses are assigned 
accarding to a two-level hierarchy: a Class A, B, or C 
“network number” part and a host part. Assumptions are 
made by the rest of the Internet that all hosts witin a 
network (even a Class A network with 16 millian hosts) 
are capable of “direct” connectivity without (externally 
visite) routing.? Several people have ed that extra, 
optional levels be added to the two-level hierarchy, and 
four RFCs (ARPA memos) have been released with 
various proposals over the last several months. As of dus 
writing, the issue is mot yet settled. 

6. Implementing a Distributed Resting Algoriiha 

A variety of distributed routing algonthms have teen 
used, with the ARPA Internet serving as one important 
example. I will now describe an algonthm often used in 
Internet Protocol networks; many variations east on this 
comnon theme. 

For each destination, a routing table entry contains the 
following information: 


2 The ARPANET as a single Class A “local” 
network in the A. Intemet, even though it spans 
the continental US and parts af Europe and the Pacific. 
Even though the ARP, is not fully interconnected 
at the physical level, it does its own intemal routing 


Soe ee 
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1, The hardware interface om which such packets 
should be sent. 


2. The node to which such packets should be addressed 
at the link level (same as the destination if the 
hardware can reach it directly, the link address af an 
intermediate gateway otherwise). 


3. A metric that indicates the route’s “cost”. (Cost is 
typically just a “hop count,” althouch it might also 
GD the relative speed or loacing factor af a 


Each rode starts with its routing table saat anly its 
directly accessible neighbars ("neighbars” could mean a 
mode on the far end of a point-topoint link, ao, 
collectively, all the nodes cn a shared network such as an 
Ethemet or local packet radio channel). The metric far 
each neighbor reflects the cost of the link to that neighbor. 


Each node pericdically broadcasts its routing tables to all 
neighbors. a node receives such a table broadcast 
from a neighbor, it examines each entry to see if it refers 
tO a destination that was previously unknown in its own 
routing table, or reflects a metric that is lower than the 
value associated with an destination already in the node's 
routing table. If either condition is true, then the node 
inserts the new extry into its own table after incremexting 
the metric to indicate the “cost” of the link to its neighbor. 
In this way, connectivity information “diffuses” throughout 
the network, and packets sre routed along paths that favor 
the mamnwmn cH o coum (depending an the 
mearing of the metric). When a node receives a routing 
table entry from a neighbor that contains a metric equal to 
or higher than an entry already in its own table for the 
Sarne destination, die node might deade to accept the new 
entry bled keeping it in reserve when the preferred 
route fails. 


To assure rapid recovery from a link failure or network 
recortiguration, nodes often "poll" thar neighbors 
ey to assure themselves that they’re still there. If 
a pol fails for sce pericd of time, all routing table 
ete to that neighbor are removed, and an 
attemmt is made to disseminate dis infonmaton to the 
other neighbors that are stil up. 

As mentioned, myny variatioxs and enhancements are 
possible an this basic theme. For example, it has been 
Observed that "good news” (the availatility af a new node 
or link) “travels fast,” while “bad news” (the failure of a 
node or link) "travels slowly.” The polling rate is dearly a 
el ioc ald oe mim mize the time needed to detect 
axxd recover a failure at the expense of extra network 
traffic. Other schemes attempt to avaid polling by acting 
only when a local client “complains” that a give: node 
appears to be inaccessi tie. 


With certain algorithms, it is possible to have transient 


“routing loops,” where packets are forwarded endlessly. 
Fortunately, this need not be catastroohic in a network 
based in IP because the “time to live” ) field bounds 


the number of hops a datagram is allowed to make. As 
long as the updated routing information is allowed to 
propagate, however, the netwark will eventually recover. 
Qne problem that can occur in such a disuibuted scheme 
is that a node muy advertise, either acadentally or 
malidously, that it can reach every other node in the 
network with zero cost. Other nodes may then be gullible 
enough to accepr this information and decade to route 
every packet to the offending node witch discards them, 
effectively crashing the network [3]. It may be necessary 
to establish "sanity checks” or encrypacbased procedures 
to establish the authendidty and reliability of routing 
informaton. 


7. Cencusions 


I have only ogra! Scratched an invdved PIC one 
that has been the subject of many books and learned 
journal articles. Nevertheless, I believe I can make 
several early recommendanons that should ease the 
construction of our network and expenmentation with 
practical routing algorithms: 
e The use of a common datagram protocol at the 
network level (i.e., the ARPA Intemet Protocol, IP) 
greatly simplifies ee routing problem. Gnoe a 


explating a datagram network's ity to Ficeaty a 
Sisco am aeons information may also be 
can take full advantage of routing 
agai that dynamically balance link traffic. With 
the sender always has the option of taking partal 
or full manual control of routing with the “source 
route” option, if desired. 

@ Network addresses should encode, in a hierarchical 
way that conserves address bis, the location of a node 
to reduce the amount of routing information that must 
be stored at each node and propagated throughout the 
necwork. 

e A distributed routing algorithm should be used to 
avoid dependence on a central site and to allow 
maximunn flexibility. 


e Early emphasis should be made on establishing a 
standard protocd for the exchange of routing 
information (the ARPA Exteriar Gateway Protocal, 
EGP, may be suitable for this purpose). 


° oda | ithms, particularly those used 

ly i the ARPANET ard in the ARPA Internet 

should be investigated and tested to determine their 
suitatility for widespread amateur use. 
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Abstract 


This paper proposes the adoption of an 
extended version of CCITT recommendations X%3 and 
X.28 for use in Amateur radio Terminal Node 
Controllers. The various X%3 parameters andX.28 
commands and service signals (messages) are out-— 
lined and the extensions in place in the V-2 soft- 
ware implementation on the VADCG (Vancouver Amateur 
Digital Communication Group) TNC are discussed. 


Terminology 


This paper is semi-tutorial in nature and is 
intended for Amateur packet radio operators. Some 
of the terms used in the official X.28 protocol 
document have been translated into terms that hope- 
fully may be more familiar to the readers. For 
example, the word 'TNC' is used instead of 'PAD' 
and the word 'terminal' is used instead of 'DTE! 
and in actual usage may be a microcomputer running 
host programs or a terminal emulation program. The 
terms I am using come from a variety of disci- 
plines. My apologies if this makes it more 
difficult to understand rather than less so. 


The Problem 


In 1979, the VADCG TNC was the only one avail- 
able and the software I had written for it only 
allowed two commands = control-Y caused a dis- 
connect and a call sign followed by control-X 
caused a connection to be made. The very limited 
number of commands and the availability of only one 
version of software made it very easy for the new 
user to learn to use even though it was not very 
flexible. 


The situation at the beginning of 1985 is 
quite different. There are now about 6 different 
TNCs available and three different protocols avail- 
able, most with several different flavours or 
versions. Each combination of TNC and software has 
its own unique set of user commands. The more 
recent versions have a large and very flexible set 
of commands. In order to use the TNC efficiently, 
the user must learn his TNC's commands. With 40 or 
more commands frequently available, this becomes 
time-consuming. Furthermore, when the user tries 
to use the same commands on a different TNC or on 
the same TNC using a different link-level protocol, 
the commands are likely not to work and another set 
of commands must be learned. This learning process 
may be slowed by lack of advice from users with 
different command sets. 


But perhaps the most serious problem that the 
lack of standardization of the command set causes 
is that application programs written for host 
computers will not be transportable. A special 
version for each case will have to be written. 
This situation has the potential of getting worse 
as new levels of protocols are developed, new TNCs 
become available andas new programmers begin to 
write software for TNCs. 


B.C. V6X 1E1 
278- 5601 


The Solution 


The commercial world ran into these same 
problems in interfacing ASCII terminals to the 
Packet Switched Public Data Networks (PSPDN) and 
developeda set of standards to solve their prob- 
lems. The CCITT adopted Recommendations X.3 and 
X28 in 1977. Recommendation X.28 defines the 
commands the terminal user sends to the PAD (Packet 
AssemblerDisassembler) and the service signals 
(messages) sent from the PAD to the terminal user. 
The PAD performs a similar function to the TNC 
(Terminal Node Controller) in the Amateur environ- 
ment. Recommendation X.3 defines a set of para- 
meters in the TNC which tailor its control of the 
terminal. In the ISO protocol model, X.3 and X.28 
are a Level 6 or Presentation level protocol. To 
quote the OSI draft, "The purpose of the Present-— 
ation layer is to represent information to communi- 
cating application-entities in a way that preserves 
meaning while resolving syntax differences." 


In August1984 Ireceivedinformation on the 
CCITT X.3, X.28 protocols and realized that these 
standards could solve most of these problems if 
they could be implemented on all TNCs. On August 
20, 1984 I wrote to the ARRL Ad Hoc Committee on 
Amateur Radio Digital Communication proposing the 
adoption of these standards. I also began recoding 
the V-2 software I was writing to use these 
standards. The proposal received a favourable 
response at the September, 1984 Committee meeting. 
The implementation described in this paper was 
completed in October, 1984. At the Committee 
meeting in November, 1984 I was asked to prepare a 
paper detailing my recommendations for a protocol 
based on the CCITT X.3 and X.28 protocols to be 
used in the Amateur packet radio environment. This 
is that paper. 


The environment that the X.3/X.28 protocols 
were intended to work in is very similar to that 
found in most Amateur packet radio stations. How- 
ever there are some minor differences which neces-— 
Sitate some deviation from the official recommenda- 
tion. X.3/X.28 was intended to interface ASCII 
terminals and because of this, it only expected 7- 
bit ASCII characters to be used. In the Amateur 
environment, it is sometimes useful to transmit 8- 
bit binary data such as in object code. Some modi- 
fication and extension of these protocols has been 
made in this recommendation to accommodate this 
type of usage. 


Additionally, the terminal user in the commer- 
cial environment had no control over the tailoring 
of the operation of the data link level software. 
This recommendation includes extensions to stan- 
dardize some of this control the Amateur user is 
already familiar with. While an attempt has been 
made to keep the X.28 commands and messages as 
Similar to the official recommendation as possible, 
several have had to be changed to be more meaning- 
ful in the Amateur packet radio environment. These 
changes are similar to the type of changes made by 
commercial users when adapting these protocols to 
their own environments. 
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Recommendation X28 


The first problem encountered in establishing 
communication between the terminal and TNC is to 
initialize the TNC to the proper data rate and data 
format oftheterminal. A sequence of characters 
are sent by the terminal to the TNC until the TNC 
recognizes the speed and format of the terminal and 
responds with an initial message. This function is 
commonly known as ‘AutoBaud' or ‘Autospeed' or 
"Adaptive speed'. UnfortunatelyX.28 does not de- 
fine any character sequence for implementing this 
function and in practice there are several differ=- 
entmethods employed in the data communications 
industry. The current V-2 implementation on the 
VADCG TNC uses alternating '.' and ',' (period and 
comma) for detection of Baud rate and format. This 
system is superior to single character AutoBaud 
implementations because it can detect the type of 
parity and number of data bits used in addition to 
the Baud rate. In some applications it may be 
desireable to have the TNC always come up at a 
fixed Baud rate and data format and in this case 
the autoBaud function may be unnecessary. 


After communication has been established be- 
tween the terminal and TNC, both data for the link 
and X.28 commands for the TNC may be sent by the 
terminal user to the TNC. Likewise, messages gen- 
erated by the INC and data from the link can now be 
passedtothe terminal at this time. Since both 
data and commands are being multiplexed over the 
TNC/terminal connection, the question arises as to 
how to differentiate the two types of data. The 
TNC can operate in two modes: while in ‘command 
mode* characters received from the terminal are 
interpreted as commands and while in 'data trans- 
fer' mode the characters are interpreted as data 
intended to be passed on the link. The TNC will go 
from data transfer mode to command mode when it 
receives the X.3 command escape character defined 
by X.3 parameter #1. This command escape character 
may be set to any value by issueing an X.28 command 
to modify the setting of an X.3 parameter. 


The problem of transmitting the command escape 
character as data is solved by transmitting two 
escape characters in succession from the terminal. 
This sequence is recognized by the TNC and causes 
the TNC to pass a single escape character to the 
link. By using this 'byte stuffing' technique it 
is possible to transmit any combination of char- 
acters as data to the link. This technique is 
convenient for terminal users and for file transfer 
of ASCII files but it is not full data transpar- 
ency. For transmission of binary files by host 
computers whose file transfer program cannot handle 
this 'byte stuffing' technique, another system must 
be used. X.3 parameters may be set so that the TNC 
does not recognize any characters as having special 
meaning = including the command escape character. 
(See X.3 parameters 3, 12,13 and 15) Now we have 
full data transparency. 


But we have a new problem. After we have 
transferred our transparent data, how do we get 
back into command mode? We can't use a command 
escape character to do it so it has to be done 
another way. The setting of X.3 parameter 7 toa 
value of 8 causes the TNC to go into command mode 
when a break signal is generated by the terminal. 
Some terminals and computers are not capable of 
generating a break signal but can get back into 
command mode by resetting the TNC causing it to 
return to the initial default values of the X.3 
parameters. 


Resetting of the TNC seems like an extreme 
measure and other alternatives for users incapable 
of generating a break signal should be found. This 
is an area where the standard may need to be ex- 
tended to meet the special needs of the Amateur 
Radio environment. My suggestion is to use a 
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special sequence of a number of characters followed 
by sufficient time to cause the idle timer to 
expire. (See X.3 parameter 4) At expiry of the 
timer, the TNC could check the preceding characters 
and enter the command mode if a match is found. 
This method should be virtually foolproof because a 
computer would never allow this much wait time 
while sending a transparent file. This is an area 
of further study. 


Kobimmands 


X.28 commands are not case-sensitive. They 
can be typed in either upper or lower case or mixed 
case with the same results. Commands are term-— 


inated by carriage return <er> or by't'. 
Officially, X.28 has defined the following 8 


commands: 


SET <parameter list> 
To change X.3 parameter values 

PAR? <parameter list> 
To display the current value of specified X.3 
parameters. 

SET? <parameter list> 
Sets and then displays the current value of 
specified X.3 parameter values 

PROF <identifier> 
To set the X.3 parameters to a standard set of 
values 

STAT Request status of TNC 

CLR -# To terminate a link connection 

RESET = To reset a link connection 

INT ~ To transmit an interrupt packet 


This is a fairly short list of commands. This 
is because the function of most of the TNC commands 
we are familiar with is done by modification of the 

rm} parameters. 


There are a number of problems with using this 
command set in the Amateur packet radio environment 
which I will discuss in the following paragraphs. 


X.28 does not define a command used to estab= 
lishaconnectionbecausethe format of such com- 
mands is very environment-specific. In the V-2 
implementation the following command is used to 
establish a link-level connection: 

CONNECT <call-sign><cr> 

The call-sign is entered as an ASCII field in 
either upper or lower case. It is converted to 
upper-case and padded on the right with ASCII 
blanks. In the V-2 implementation this field is 7 
characters long with the 7th character identifying 
an extension to the call sign. In implementations 
for other protocols, this field may be only 6 
characters long. Additional information may need 
to be specified when establishing a connection when 
digipeating is used and when network level proto- 
cols are developed for Amateur packet radio. This 
information may optionally follow the call sign in 
the 'CONNECT' command but this is a subject for 
future consideration for incorporation into a stan- 
dard. With a network level it may be desireable to 
use the 'CONNECT' command to establish a network 
level connection and use 'LINK' to establish a link 
level connection independently. 


The X.28 'CLR' (clear) command is used to 
terminate a connection. Unfortunately, this 
command does not correspond to current Amateur 
packet radio conventions where the 'DISCONNECT' 
command is usually used. I propose we use the 
"DISCONNECT' command for this purpose. When net-— 
work level protocols are developed, the 
'DISCONNECT' command can be used to terminate a 
network level connection and the 'UNLINK' command 
can be used to terminate a link level connection. 


The X.28 'INT' command has no counterpart in 
the Amateur packet radio environment at the present 
time. There is no such thing as an ‘interrupt 


packet’ in current link level protocols. When 
higher level protocols are implemented, there may 
be a need for this command. This is a subject for 
future consideration. 


The 'SET' command should be implemented exact- 
ly as described in the X.28 recommendation. As an 
example, to set X.3 parameter 5 to 3 and parameter 
21 to 128 type the following: 

SET 5:3 21:128<cr> 
The parameter numbers and values are entered as 
pairs of decimal numbers. Any blank or non-numeric 
character can be used as a separator between the 


numbers. The above could be entered as follows: 
set 5 321128<cr> 
The X.28 'PAR?' command parameters is a list 


of X.3 parameter numbers whose values are to be 
displayed. The parameter numbers are entered in 
decimal. 


The X.28 'SET?' parameters are the same as for 
the 'SET' command above. The function of the 
'SET?' command is basically similar to that of the 
"SET' command followed by the 'PAR?' command and 
because of this redundancy it has not been support- 
ed in the current V-2 implementation. However, 
since it may be more convenient, this command 
should be considered optional. 


The X.28 'PROF' command sets the X.3 para- 
meters to a particular set of values or 'profile.' 
The identifier in the command is a decimal number 
which identifies the particular profile desired. 
X.28 defines two profiles = simple and transparent 
but many networks offer other profiles tailored to 
the characteristics of a particular terminal or 
application. 


The transparent profile is used when the TNC 
needs to be "invisible" to the user. Commands can 
not be used, no messages are generated by the TNC 
and editing and echo are not supported. 


The simple profile supports commands and uses 
a set of X.3 function which require a minimum of 
terminal features. Messages are generated by the 
TNC and echo and flow control are enabled. Data is 
forwarded whenever a control character is received 
by the TNC. 


The 'initial profile' is the set of X.3 para- 
meters that are in effect when the TNC is initial- 
ized or powered up. It is usually similar to the 
simple profile. TNCs that support non-volatile RAM 
(NOVRAM) can have the ability to tailor their 
initial profile while others can only support a 
fixed initial profile burned into EPROM. The 
"PROF! command is particularly useful in the latter 
case because it can usually reduce the amount of 
time required to tailor the X.3 parameters after 
powering on the TNC. It can also be useful when 
the TNC is sometimes switched to a different 
function where substantially different character- 
istics are required. This paper recommends that 
the 'PROF' command should be considered optional 
but desireable. It is not supported in the current 
implementation of V-2 but will be implemented in a 
future release. 


The 'STAT' command takes no parameters but 
causes the TNC to display the current connect 
status of the TNC. This command is not presently 
implemented on V-2 since the connect status of the 
TNC is indicated by two other methods. However, 
this command should be implemented since TNC soft- 
ware capable of multiple links and connections will. 
become available and the connection status of a INC 
may be difficult to determine without this command. 


The 'RESET' command currently is not supported 
because the current link level protocols do not 
support a reset packet. This command should be 
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implemented when new protocols are developed which 
support this function. 


You will note the very small number of 
commands needed by X.28 to control a TNC. Most 
functions are performed by the setting of X.3 para- 
meters using the 'SET' command. The reduction in 
the number of messages and commands can reduce the 
learning period for a non-English speaking user and 
possibly reduce the time for programmers to recode 
the software for use with a different language. 


In general, functions which control an on/off 
type of condition or control a value that can be 
specified in a single byte can be controlled by X.3 
parameters. For example, the TNC either echoes the 
characters from the terminal or it doesn't. An- 
other example is the setting of the number of 
retries attempted on the link. 


On the other hand, functions which cause 
immediate action or require the entry of multiple 
characters are unsuitable for incorporation into 
X.3 parameters and so require specific commands. 
An example ofthisis the 'CONNECT command which 
requires the provision of a call sign and causes an 
immediate change in the operation of the TNC. 


One function common to all TNC command sets is 
the ability to set the station call sign and so 
should beincorporatedinto a standard. Irecom- 
mend the following command for this function: 

MYCALL <call-sign> 

This format is similar to that of the 
"CONNECT' command described above. At the present 
time the V-2 implementation uses the 'CALLSIGN' 
command to perform this function but the 'MYCALL' 
command mnemonic is more familiar to users of TNCs 
and so I will be changing it in future releases. 


The commands described in this section are not 
meant to be the only commands that should belong in 
a TNC. They are intended to be a set of commands 
that should be standardized in every TNC because of 
a common need for these functions. If a specific 
function is only used in one implementation there 
is no need for standardization. However, if a 
function is common to more than one implementation, 
then there should be an attempt made at providing a 
standard way to controlthatfunction. No doubt, 
as Amateur packet radio develops, new commands will 
have to be incorporated into this recommendation. 


To summarize this section, this paper recom- 
mends the incorporation of the following six 
commands into every TNC. 

SET, PAR?, CONNECT, DISCONNECT, MYCALL, STAT. 
The PROF and SET? commands are optional. 


Metisages 


X.28 messages are frequently called service 
Signals. The public packet-switched networks do 
not usually implement the official X.28 message set 
precisely as it is defined. This is because the 
messages are not human engineered and in many cases 
may not be suitable for a specific environment. 
This is also the case in the Amateur Radio environ- 
ment. However a number of the messages can be 
used. The following list is a subset of the 
official X.28 message set that I am recommending be 
used exactly as defined. 


Line feed 
Acknowledgment of a command. 
* 
Command mode prompt signal. 
xxx 
Indicates that the line delete function is 
completed. 
ERROR 
Command error. 


PAR <nsn> 
Response to SET and SET? commands. The n's 
indicate the parameter number and value in 
decimal respectively. 

PAR <n: INV> 
Response to an invalid parameter setting in a 
SET or SET? command. n is the parameter 
number. 


The following list contains messages which are not 
exactly as defined by the official X.28 recommend- 
ation but which I recommend be used in the Amateur 
packet radio environment. 


LINKED <call-sign> 
Indicates that a data link connection has just 
become establishedor aresponse to the STAT 
command when a data link connection is 
established. 

UNLINKED 
Response to the STAT command when a data link 
connection is not established. 

LINKING <call-sign> 
Response to the STAT command when a data link 
connection is being attempted. 

UNLINKING <call-sign> 
Response to the STAT command when a data link 
connection is being broken. 

UNLINKED <call-sign> <reason> 
Indication that a data-link connection has 
been broken or could not be established. The 
reason is given after the call-sign and can be 
one of the following: 

BUSY - _ The indicated station is busy. 

REM - The remote data link partner terminated the 
link. 

REMERR - The remote station detected a protocol 
error. 

NORM - Zocal DISCONNECT command. 

NORESP - The station did not respond. 

PROT - Protocol mismatch. 

ERROR - Terminated by link protocol error. 

TIMOUT -— Excessive timeouts on link. 

INV = Requested facility not supported. 


Some of the reasons refer to facilities not 
supported in all link-level protocols. In this 
case, these reasons need not be used. However, 
when these facilities are available, they should be 
implemented as shown. Other reasons for link term- 
ination will be the subject of future standard- 
ization attempts. 


It should be noted that the words, "link, 
linked, unlinked, etc." are used instead of the 
words, "connect, connected, disconnected, etc." 
even though the latter terms are in more common use 
at the present time. This was done to avoid future 
confusion because of terminology. In the ISO 
model, "connections" may be established at all 
levels. There are link level connections, network 
level connections, transport level connections, 
session level connections, etc. In the future, 
TNCs will likely have software to support multiple 
protocol levels, not just the link level as at 
present. TNCs capable of supporting multiple net- 
work level connections and multiple link level 
connections simultaneously will likely appear. 
When this happens, the term "connection" used with- 
out qualifiers will be ambiguous and cause some 
confusion. The term, "link" refers only to the 
data link layer and its use should reduce this 
potential problem. I believe that the term, 
"connection" without qualifiers should only be used 
to refer to a network level connection. 


X.28 does not define the initialization 
message which apears when the TNC is initialized 
and I am making no recommendation in this area. 
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Recommendation X.3 


In 1984, the official X.3 recommendation 
defined22 parameters used to tailor the way the 
TNC controls the interface between the TNC and 
terminal or host computer. Unlike the X.28 recom-— 
mendation which needed substantial modification to 
adapt it to the Amateur packet radio environment, 
these X.3 parameters can be implemented almost 
exactly as describedin the official recommenda- 
tion. For the Amateur packet radio environment, 
this paper recommends some extensions to this set 
to provide additional tailoring of the terminal 
interface, tailoring of the operation of the link 
interface and to control operation of the network 
level if implemented. 


In October of 1984, the V-2 implementation on 
the VADCG TNC supported an additional 14 parameters 
beyond the 22 used by the official recommendation 
to provide this additional control. The parameters 
supported in this implementation are summarized in 
Table 1. The officialX.3 parameter values which 
are not supported are indicated and extensions to 
the standard are also indicated. All parameters 
beyond 22 are extensions. The default values in 
the distributed software are also indicated. These 
defaults should not be considered as part of this 
recommendation but they do serve as an example of 
an ‘initial standard profile’. 


In this implementation the X.3 parameters have 
been set up aS a contiguous string of bytes in 
memory. The first byte being the value of para- 
meter land it is recommended that the parameters 
be implemented in this way. Each byte has a set of 
legal values defined by this recommendation. The 
software should not allow non-legal values to be 
set into these parameters. 


Parameter 1 defines the character sent to 
Switch the TNC from data transfer mode into command 
mode. While the official standard only permitted 
values of 0 and 32-326 to be specified, I have 
extended this range to allow all 8=bit byte values. 
This was done because TNCs are frequently used with 
host computers rather than ASCII terminals and so 
are capable of transmitting80bit characters. A 
value of 0 set in parameter 1 prevents escape from 
data transfer mode. by the transmission of a command 
escape character. Only one command can be issued 
from the terminal per escape. The TNC reverts back 
to command mode after each command is issued. 
Reception of the escape character also caused any 
accumulated data received from the terminal to be 
forwarded as a packet. 


Parameter 2 controls whether the TNC will echo 
characters received from the terminal. 


Parameter 3 defines characters which the TNC 
recognizes as a signal to forward any accumulated 
data received from the terminal and transmit it as 
a packet on the link. See parameters 1, 4 and 33 
for other conditions which cause accumulated data 
to be forwarded. Note that values in parameter 3 
can be added together to get some forwarding com- 
binations that are not standard in the official 
recommendation. For example, a value of 10 can be 
specifiedto cause forwarding on carriage return 
(CR), DEL, CAN and DCc2. 


Parameter 4 defines a time interval of 
terminal inactivity which is used to forward any 
accumulated data as a packet. The timer is started 
each time a character is received by the TNC. If 
it expires, the data is forwarded. This forwarding 
method is disabled if the parameter is set to 0. 


Parameter 5 defines the type of flow control 
indication is to be used by the TNC to regulate the 
flow of data from the terminal. In addition to the 
X-ON/X-OFF flow control method defined in the 


official X.3 recommendation, the TNC can also con- 
trol the RTS (Request to Send) line on the terminal 
interface to indicate whether it is ready to accept 
data or not. An active RTS line indicates that the 
TNC is ready to accept data. This extension was 
necessary to support the transfer of non-ASCII data 
(such as object code) by host computers to the TNC 
while still retaining flow control capability. The 
X-ON/X-OFF protocol is not capable of doing this. 


Parameter 6 controls the use of X.28 messages 
by the INC. These messages can be disabled as is 
frequently necessary when the TNC is connected to a 
host computer rather than a terminal or when the 
TNC is to remain transparent to the user. The 
network dependent format service signals are not 
supported because this requires a protocol layer 
that is not used in Amateur TNCs at the present 
time. It is a subject of future consideration when 
the protocols are in place that can support this 
function. 


Parameter 7 determines the action of the TNC 
when it receives a break signal from the terminal. 
The only values that are supported by the V-2 
implementation are 0 and 8. Value 8 provides an- 
other way to escape to command mode for terminals 
which support the break signal. It may be partic- 
ularly useful for host computers wishing to switch 
from a transparent mode of operation after trans- 
ferring a file. Values 1,2,4,5, and 21 are not 
supported because there are no interrupt packets, 
reset packets or any way to indicate the detection 
of a break in a packet using the current Amateur 
link level protocols. Their use should be recon- 
sidered when higher level protocols which support 
these functions become available. Although not 
implemented at present, value 16 which supports the 
ability to flush TNC data for the terminal is 
useful. 


Parameter 8 can be set so that the TNC will 
discard all data for the terminal. The only use 
for this feature at the present time is for testing 
purposes. When session level protocols are imple- 
mented in Amateur packet networks, this feature 
will become useful. It is easy to implement. 


Parameter 9 controls the number of padding 
characters (ASCII nulls) which are sent to the 
terminal after every carriage return character. 
This is frequently required by hard copy terminals 
which require extra time to perform a carriage 
return. Some video terminals and terminal emula- 
tion programs require extra time as well. In the 
V-2 implementation the padding characters are 
actually sent but this function may be implemented 
by adding the equivalent amount of time fill as 
well. The official X.3 recommendation only allowed 
up to 7 padding characters but the V-2 implementa- 
tion allows upto 255paddingcharacters or equi- 
valent time fill. 


Parameter 10 controls the point where long 
lines are broken or folded so that they display as 
multiple lines. This has its main use with RTTY 
terminals to prevent the last characters in a long 
line from overprinting at the end of the line. 
Some video terminals do not support line folding 
and may need to use this feature. 


Parameter 11 indicates the speed of the 
terminal. Take special note that this parameter 
cannot be changed by the X.28 SET or SET? commands. 
It is a read only parameter that is setbythe TNC 
initialization process or by the AutoBaud routine. 
Its only use at present is to determine what speed 
the terminal is running at if this is not known. 
It will have other uses when session level proto- 
cols are used in Amateur packet networks. The 
values indicated as not being supported are Baud 
rates that the V~2 AutoBaud routine does not sup- 
port. Baud rates not in the list which are imple- 
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mented should use values above 18 and willbethe 
subject of future standardization efforts. 


Parameter 12 defines the type of flow control 
Signals which the TNC will act upon to control the 
flow of data from the TNC to the terminal. The 
functions provided by this parameter have been 
extended beyond the official recommendation in 
order to be able to pass binary data to the 
terminal or host computer. An additional flow 
control method using the CTS (Clear to send) line 
from the terminal has been provided. If value 2 is 
set, the TNC will only send data to the terminal 
when the CTS line is active. Note that X-ON/X-OFF 
flow control cannot be used while transferring 
binary data. When X-ON/X-OFF flow control is spe- 
cified here, the X-ON and X-OFF (DCl and DC3) 
characters are not forwarded. 


Parameter 13 controls the insertion of line 
feeds by the TNC after carriage returns either 
going to or coming from the terminal and after 
carriage returns being echoed back to the terminal. 
Any combination of these insertions may be 
selected. 


Parameter 14 controls the number of padding 
characters (ASCII nulls) to be inserted after every 
line feed being sent to the terminal. This feature 
is used with terminals which take a long time to do 
a line feed operation. This is somewhat similar to 
parameter 9 and equivalent time fill can be used 
instead of sending padding characters. 


Parameter 15 controls whether editing opera- 
tions can be performed on dataaccumulatedbythe 
TNC in data transfer mode but which have not been 
forwarded yet. Editing is always available in 
command mode. The characters acted upon for the 
editing functions are defined in parameters 16, 17 
and 18% $$Editing is normally used with terminals 
rather than host computers. The V-2 implementation 
does not turn off idle time forwarding automatic-— 
ally when editing is specified as per the official 
X-3 recommendation. Care should be taken with the 
specification of parameter 3 to ensure that data is 
not forwarded before there is a chance to edit it. 


Parameter 16 defines the editing character the 
TNC acts upon to delete the previous entered char- 
acter from the unforwarded accumulated data. The 
V-2 implementation uses the range 0-255 rather than 
0127 which is the official X.3 recommendation. 


Parameter 17 defines the editing character the 
TNC acts upon to delete the unforwarded accumulated 
data. The V-2 implementation uses the range 0-255 
rather than O127 which is the official X.3 
recommendation. 


Parameter 18 defines the editing character the 
TNC acts upon to redisplay the unforwarded accumu- 
lated data. This is mainly used to redisplay 
edited lines on printing terminals which do not 
have the ability to erase characters. The V-2 
implementation uses the range 0-255 rather than 0Q- 
127. 


Parameter 19 selects the type of signals that 
will be returned to the terminal when handling 
editing characters. The V-2 implementation allows 
for tailoring these signals for either printing or 
video display terminals. For example: for the 
delete previous character operation the TNC will 
return the character "/" for a printing terminal or 
the character sequence "<backspace>, <space>, 
<backspace>" for a video display terminal. 


Parameter 20 is used to specify which char- 
acters will not be echoed to the terminal when echo 
is enabled by parameter 2. Note that the flow 
control characters X-OFF and X-ON are never echoed. 
Note that the values in this parameter can be added 


together to get character sets which are not in the 
official recommendation. For example, a value of 6 
may be specified which prevents echo of LF, VT, HT 
and FF. 


Parameter 21 specifies whether the TNC will 
generate the parity bit in the data sent to the 
terminal and whether parity will be checked on data 
from the terminal. This parameter is not used in 
the V-2 implementation. The AutoBaud routine in V= 
2 generates a like parity to that supplied by the 
terminal but no action is taken on parity errors in 
data received from the terminal. The official X.3 
specification seems to be vague as to what action 
is to be taken on parity errors or what type of 
parity (even, odd, mark, space, etc.) will be set 
by this parameter. However, I recommend implement- 
ation of this parameter when its function is clear 
and useful. 


Parameter 22 specifies the number of line feed 
characters that the TNC will sendtotheterminal 
before stopping the sending of additional char- 
acters. The sending will recommence when an X-ON 
character is received from the terminal. This 
function allowstheterminaluser to read all the 
information before it is scrolled off the screen. 
The X.28 message "PAGE" is senttotheterminal to 
indicate the reason the data transfer to the 
terminal has been stopped. 


Parameter 23 defines the number of additional 
characters that the TNC can receive from the 
terminal when the flow control method specified by 
parameter 5 acts to stop data from coming in from 
the terminal. This parameter and all remaining 
parameters described here are extensions to the 
official X.3 recommendation. This parameter was 
added to support a number of host microcomputers 
which do not act immediately on flow control sig- 
nals. Some microcomputers only check flow control 
Signals after the transmission of each line which 
could result in lost data if extra buffering cap- 
ability was not available at the time the TNC acted 
to suspend the data flow. 


Parameters 24, 25, 26, 27, 28 and.29 are 
extensions to allow for tailoring of the operation 
of the data link on the TNC. 


Parameter 24 defines the number of consecutive 
link timeouts (no response that will be tolerated 
before "giving up". This value is used only when a 
"CONNECT' or 'DISCONNECT' command is in progress. 
When a link is established, the value in parameter 
25 is used. 


Parameter 25 defines the maximum number of 
consecutive link timeouts that will be tolerated on 
a data-link connection before "giving up". This 
value is only used when the link is established. 
See parameter 24 for the value used when the link 
is being established or terminated. 


Parameter 26 defines the amount of time the 
TNC will wait for a response from a data link 
partner. If this time expires before receiving the 
expected response the TNC takes remedial action 
which is usually a transmission polling the partner 
for another response. The V-2 implementation on 
the VADCG TNC suspends this timer when the link is 
busy (a Signal is detectedonthe channel) so that 
timeouts are not caused by use of the communica- 
tions channel by other stations. 


Parameter 27 allows for improved usage of the 
TNC in situations where it is not possible to reli- 
ably determine whether the link channel is occupied 
or not. This is frequently the case with noisy 
links such as are encountered with satellite and HF 
channels. When a value of 1is specified, the TNC 
ignores the status of the carrier detect line and 
always assumes that the channel is clear. 
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Parameter 28 defines the amount of time the 
RTS line will be active before the data is trans- 
mitted on the data lines. This is used to support 
transmitters and modems which are slow in turning 
on. This time delay is also used to allow suffi- 
cienttime for receivers to unsquelch so that the 
first part of the data frame is received without 
error. Note that the data will not be transmitted 
until the CTS line is active too. 


Parameter 29 can be used to prevent links by 
other stations from being established. When the 
value is set to 1 the V-2 protocol responds to 
attempts to establish a data-link connection by 
indicating a 'busy' condition. 


Parameter 30 is intended for future link 
control functions. 


Parameter 31 controls whether the TNC will use 
the AutoBaud feature when re-initialized or use 
preset values for speed and format of the terminal 
interface. In TNCs which do not support non- 
volatile RAM, the value set by the terminal user 
will only be effective until the TNC is powered 
off. 


Parameter 32 controls which packets received 
by the TNC will be passedtothe terminal. If set 
to 0, the TNC acts as a filter which prevents data 
in packets not intended for this station from being 
passed to the terminal. Other values to provide 
different filtering actions should be the subject 
of future standardisation efforts. 


Parameter 33 specifies the maximum number of 
characters received from the terminal which can be 
accumulated before forwarding the data in a packet. 
This determines the maximum number of bytes in the 
data field of a packet. The actual maximum frame 
length transmitted must include the overhead of the 
various protocol layers in use as well as this 
value and the maximum value that can be specified 
may vary with different protocol implementations. 
Care should be taken when specifying this parameter 
so that frames which are greater than the link 
partner's ability to handle are not generated. I 
recommend that all implementations be capable of 
handling values of at least 128 characters. 


Parameters 34through 38 are intended to be 
used to tailor the operation of the network layer. 
It is too early in the development of Amateur 
packet radio protocols to standardize network layer 
functions. The current use of parameter 34 in the 
V-2 implementation is shown in Table 1 but it is 
not the intent of this paper to recommend standards 
in this area. 


Parameter 39 determines how the TNC controls 
the Receive Line Signal Detect (Carrier Detect) 
line on the terminal interface which is pin 8 on 
the standard EIA RS-232 interface connector. If 
set to 0, this line is always active. If set tol, 
this line is only active when a data-link connec- 
tion has been established. This feature is useful 
when the TNC is connected to a host computer. 


Parameter 40 controls the masking of data bits 
in the characters being sent to and received from 
the terminal. If this value is 255, the TNC will 
pass 8-bit characters to and from the terminal. If 
the value is 327, the high order bit will be masked 
off (set to 0). Any bits can be masked off. The 
masking values are easier to understand when 
converted to binary. 


Recommendation X.29 


Although not discussed previously, it seems 
appropriate that CCITT recommendation X.29 be men- 
tioned because it is closely related to the X.3 
protocol. X.29 is a protocol which allows a remote 


TNC to both inspect and change the X%.3 parameter 
values. This allows an application program to co- 
ordinate its operation with that of the remote 
terminal. For example, the application program 
could disable echo by altering X.3 parameter 2 
while a password was being entered. In the IS0 
model, X.29 would be called a Level 5 or Session 
level protocol because it provides the means to 
coordinate the operation of the remote Presentation 
level (X.3/X.28). A number of significant advan- 
tages of the X.3/X.28 protocols will not be real- 
ized until a Session level of some kind such as 
X.29 is implemented in Amateur packet networks but 
it is not within the scope of this paper to make 
recommendations on Session level protocols for 
Amateur use. 


Implementations 


The only full implementation of the X.3 and 
X.28 protocols on Amateur TNCs that I am aware of 
is with the V-2 protocol on the VADCG TNC or Ashby 
boards. The Ashby board requires a hardware modi- 
fication for the software to work. I understand 
that Terry Fox, WB4JFI with AMRAD is working on 
implementing this protocol with AX.25 on the VADCG 
TNC with his daughter boardmodification. He has 
been sent a copy of this implementation. TAPR rep- 
resentatives have indicated that they will provide 
X.3/X.28 as an optional command set on the TAPR 
board at some future date. Phil Karn, KA9Q, who is 
developing packet software for the Xerox 820 board 
is also interested in using these protocols. From 
discussions I have had with representatives of many 
of the Amateur packet radio organizations, I feel 
there is widespread support for the development of 
standards based on the X.3 and X.28 protocols. 


Coordination of implementation 


Some problems may arise when implementing 
these protocols in other TNCs or with other link=- 
level protocols. The following paragraphs are 
guidelines for implementors. 


Not all TNCs will support all the functions 
defined in the X.3 parameters. An invalid para- 
meter message should be returned when an attempt is 
made to set an unsupported value. 


Functions which can be implemented in X.3 
parameters but which are not defined in the current 
recommendation should be implemented in parameters 
above 40. 


When these new parameters are used in an 
implementation an attempt should be made to coordi- 
nate these parameters with other implementations so 
that the same parameter is not used for different 
functions or that different parameters are used for 
the same function. On request, I have volunteered 
to act as a coordinator for this effort within the 
ARRL Ad Hoc Committee on Amateur Radio Digital Com- 
munication. The Committee will use its facilities 
to act as a clearing house for information on 
X.3/X-28 implementations for individuals who are 
planning extensions to these recommendations. 
Implementors should write to the Committee or 
directly to me at the address at the beginning of 
this paper. 


Many functions are not suitable for control by 
X.3 parameters and will require extensions of the 
X.28 command and message set. An attempt to co- 
ordinate these extensions should be made. Imple- 
mentors should communicate details of these exten- 
Sions to me or the Committee as described in the 
previous paragraph. 


Summary 


The protocol described in this paper has been 
tested by many Amateurs in a number of countries 
with good results and it is estimated that several 
hundred thousand users of public data networks use 
the X.3 and X.28 protocols daily. The temporary 
disruption caused during the conversion from the 
old command set to the X3/X.28 protocols is only a 
small inconvenience when compared to the advantages 
of having a standard set of commands and messages 
for all TNCse This inconvenience becomes even less 
Significant when one considers the potential advan- 
tages of the X.3 parameters when session level 
protocols such as X.29 are developed for Amateur 
packet networks. 


The initial recommendations made here will 
likely be fine-tuned as a result of future discus- 
sions, feedback and coordination efforts but the 
author hopes that this paper will lead to the 
development of a widespread standard set of 
commands and responses for terminal users of 
Amateur packet radio equipment and to give 
programmers a standard interface to TNCs so that 
they may write applications that will work on all 
Amateur TNCse The recommendations made in this 
paper do not restrict the commands and messages 
used by TNCs but do propose standard ways of con- 
tr olling certain common functions. No doubt, as 
Amateur packet radio networks mature, other 
functions will need to be standardized and other 
presentation level protocols will be developed for 
special environments. 
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TABLE ] — X.3 PARAMETER VALUES 
* = default value 
# = not supported 
% = additional to X.3 standard 
REFERENCE 
1 Command escape 0 not possible 
m2 ESC character 
Le 2oye Ora) optional values 
2 Echo 0 no echo 
* echo 
3. Data forwarding 0 full packet only 
i alphanumerics 
*2 Carriage return 
4 HSC, “Bob; BNO; ACK 
6 Carriage return, ESC, BEL, ENQ, ACK 
g DEL. ‘CAN; DC2 
16 ETX, EOT 
18 carriage return, EOT, ETX 
a2 Pee: oy Vly VEE 
126 all other characters below 32 
4 Idle timer delay 0 no timer 
32 default value 
tool y. 35200 delay values in approximately tenths of a second. 
5: Flow control to “INC 0 no flow control 
I. X-ON/X-OFF (data transfer) 
2 X-ON/X-OFF (data transfer and command) 
e*4 flow control with RTS line 
6 Control of INC service sigs 0 no service signals 
1 transmit service signals 
*5 transmit service and prompt sigs 
#8-15 network dependent format service sigs 
7 operation on break *0 no action 
#1 interrupt packet ? 
#2 reset packet 
#4 indication of break service signal 
#5 interrupt and indication of break 
8 escape from data transfer state 
#16 discard output to terminal 
#21 1 + 4 + 16 combined 
8 discard output *0) normal data delivery 
1 discard output to terminal 
9 Carriage return padding *0 no padding 
L255 number of nulls inserted after CR 
10 Line folding *0 no Line. folding 
LaZ55 number of characters per line 
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11 Binary speed 0 110: bit /s 
1 134.5 bit/s 
2 300 bit/s 
3 1200 bit/s 
4 600 bit/s 
5 15. BLES 
6 150 bit/s 
1800 bit/s 
8 200 bit/s 
9 100 bit/s 
10 50. ity s 
#11 75/1200 bit/s 
12 2400 _ bit/s 
13 4800 bit/s 
14 9600 bit/s 
i 19200 bit/s 
#16 48000 bit/s 
#17 56000 bit/s 
#18 64000 hit/s 
12 Flow control to terminal *0 no flow control 
1 X-ON/X-OFF flow control 
2 flow control using CTS line 
13 Line feed insertion 0 None 
l after carriage return to terminal 
2 after carriage return from terminal 
4 after echoed carriage return 
‘ values 1 + 4 
m6 values 2 + 4 
values 1+ 2 + 4 (data transfer only) 
14 Line feed padding aa) none 
L255 number of nulls after line feed 
15 Editing 0 off 
a) on 
16 Character delete *8 BS (backs pace+t character (control-H) 
o=l;. G=lZ] other characters 
17 Line delete *24 CAN character (control-X) 
O=235 <2oHl77 other characters 
18 Line redisplay *18 DC2 character (control-R) 
O=h7,.. “hg=l27 other characters 
19 Editing service signals 0 no editing service signals 
l editing for printing terminals 
Pe editing for display terminals 
#8 editing using characters from range 32-126 
20 Echo mask x0 all characters echoed 
no echo of carriage return 
2 no echo of LF 
4 no echo of VT, HT, FF 
8 no echo of BEL, BS 
16 no echo of ESC, ENQ 
32 no echo of ACK, NAK, STX, SOH, EOT,ETB, ETX 
64 no echo of editing characters 
128 no echo of all characters in columns 1 & 2 plus DEL 
#21 Parity treatment #0 no parity detection or generation 
#1 parity checking 
#2 parity generation 
#3 value 1 + 2 
22 Page wait 2 no page wait 
Rohe number of line feed characters before waiting 
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$23 Buffer cushion *80 number of characters in cushion 
2-19, 81-254 other values 


%24 Linked timeouts *16 maximum consecutive timeouts linked 
Lad 5s.: Le 250 other values 


%25 Unlinked timeouts #5 maximum consecutive timeouts when not linked 
i=, 465255 other values 


$26 Line timeout *10 approximately 5 seconds 
1-9, 11,255 other values 
$27 Duplex line control *0 half duplex line control 
1 always assume that channel is clear 
#2 full duplex 
$28 Clear to send delay *32 approximately 1 second 
eS. 92 OO other values 
$29 Link control *0 normal 
1 links to other nodes not permitted 


$30 Unused link control parameter 


$31 Autobaud control 0 use fixed UART defaults 
* 1 AutoBaud 
$32 Received packet forwarding 0 only pass packets when linked 
* 1 pass unlinked packets 
%33 Maximum packet length *200 maximum output packet data bytes 
S299 ZOLA 50 other values 
$34 Network header 2nd byte *0 NH second byte is 00 
L290 other values 


%35 Unused network control parameter 
%36 Unused network control parameter 
%37 Unused network control parameter 


%38 Unused network control parameter 


%39 RLSD (CD) line control *0 always on 
1 indicates if link is established 
$40 Data mask *127 mask off high order bit 


255 pass all 8 bits in each byte 
0=255 range permitted 
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Formal Definition Meeting for the Packet Radio Experiment RUDAK 
to be included in AMSAT P3-C 


Dr. Karl Meinzer DJ4ZC 
Hans Peter Kuhlen DK1YQ 


During the weekend February 15 thru 17, 
AMSAT-DL hosted a formal meeting to de- 
fine the Packet payload in P3=-C. The ex- 


periment has been named "RUDAK" for 
"Regenerativer Umsetzer ftir Digitale 
Amateur-Kommunikation". 


Attending were: 


Hans Peter Kuhlen DK1YQ 


3. Moderate to small antennas should be 
sufficient for low bit error rates. 


Relating to point 3., the board agreed on 
the nominal amateur station performance 
parameters as detailed in Annex A. With 
these in mind, the second point was analy-s 
sed in great deteil with particular refe- 
rence to link-performance and modulation 
technigues available with these results: 


Program Manager RUDAK Project 


Peter Gltilzow DB20S 
Project Manager RUDAK project 


Heinz Mélleken DL3AH 
Ground Systems Manager RUDAK project 


Werner Haas DJ5KQ 
Vice President AMSAT-DL e. V. 


Karl Meinzer DJ4ZC 
President AMSAT-DL e. V. 


A. General 


After a brief review of the performance 
and capabilities of existing packet 
systems, the board set the objectives for 
the RUDAK payload as follows: 


1. Compatability of the system with the 
present AX.25 standard and the existing 
Packet Radio boards (e. G. TAPR) | 


2. Regular Amateur communication equip- 


ment should be used without the need 
of modification or intrusion. 
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Link budget considerations require 
efficient techniques for the downlink 
which today can only be achieved using 
(transparent) SSB-equipment with demo- 
dulation at baseband (audio). This 
limits the practical achievable data- 
rate to 1200 bits/s (RSM) or lower 
(BPSK); a performance better than 

12 dB Eb/No can be expected. 


. The uplink could employ standard FM~ 


equipment for straight FSK-modulation. 
Experiments by DB20S showed that 2400 
bits/s (biphase) can be handled by 
standard equipment without problems. 
It remeins to be investigated if 4800 
bits/s (NRZ) also can be handled or if 
special measures are necessary to eli- 
minate the influence of the DC-compo- 
nent (e. G. scrambling for spectrum 
shaping). Higher data rates cannot be 
achieved with standard radios. Techni- 
cal papers reviewed indicate that with 
a discriminator type of demodulator 

17 dB Eb/No are necessary for 2400 
bits/s and about 15 @B for 4800 bits/s 
(FM-threshold), The meeting concluded 
that also BPSK for the uplink is 


viable without intrusion inti equipment 
by using a high-power passive BPSK- 
modulator between transmitter and an- 
tenna or between exciter and PA. This 
approach imposes no restrictions on the 
data rate and yields also a better than 
12 dB Eb/No performance. The resulting 
spectrum needs to be investigated and 
bandwidth-limiting measures may turn 
out to be necessary. The board con- 
cluded theat in view of the long visi- 
bility of the satellite no sgnificant 
on board storage would be employed. The 
uplink using essentially ALOHA signal- 
ling should have about six times the 
capacity of the downlink. On board 
storage should be sufficient to buffer 
about ten times the packet differential 


between downlink and uplink (6-7 kByte). 


presently there is no suitable ISO- 
layer 3 network definition available, 
thus the payload initially should emu- 
late the existing digipeater function 
as defined in the AX.25 version 
2.0/Oct. 84. If a more sophisticated 
level 3 protocoll becomes available, 
the S/C will be updated accordingly. 


Design decisions taken by the board 


The board agreed on the following main 
features as design guidelines for the 
RUDAK experiment: 

- Nominal amateur equipment as defined 
by Annex A required the selection of 
the following data-rates and modu- 
lation techniques: 


Uplink: 2400 bit/s differential 
(24 cm) biphase PSK (+-90 deg) 
spectrum shaping TBD 
Dawnlink: 400 bit/s differential 
(70 cm) biphase PSK (+-90 deg) 


spectrum shaping as used in 
AO-10 
- continuous operation of the beacon in 
Mode L (24/70 cm: independant from 
the transponder passband (and AGC) 
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-"Bulletin board" i. e. cyclic repe- 
tition of information packets con- 
taining 

eupdated satellite status 
(Keppler data) and 


(telemetry) 
orbit information 
present position (MA) 

euplink parameter set to be used by 
Packet Radio Stations wishing access 
to RUDAK 
trial and error experimentation). 


(to eliminate unnecessary 


etc. 

- RUDAK programmes will be resident 
entirely in RAM facilitating software 
updates to be executed by AMSAT 
control stations via the regular P3-C 
command system. 

- Packet first-in-first-out (FIFO) 
buffer (67 kByte) plus additional 
storage consistent with available 
memory to be used. 

—- continuous self-test of the s/w with 
error correction in case of soft 
errors and auto-recovery in case of 


problems. 


The original RUDAK design constraints 
(power 5 W, Volume 5 litres, mass 5 kg) 
were reviewed. It was concluded that 
one large P3-module (300x200x40 mm) 
would be sufficient to house the digi- 
tal part of the experiment. The board 
was made aware that for a continuous 
operation of the RUDAK computer a con- 
siderably lower power consumption than 
5 W would be desirable. If this turns 
out to be impractical, the availability 
of a stand-by mode with memory reten- 
tion should be investigated. The trans- 
mitter and receiver of RUDAK will be 
built and integrated into the L-trans- 
ponder by the group building the trans- 
ponder. 


A work assignment and schedule has been 
agreed upon consistent with the AMSAT-= 
P3-C launch (Annex B). 


d. The board elected H. Kuhlen, DK1YQ, 
to compile the full RUDAK specification 
for definition of hardware and software 
requirements including the interfaces 
to the"Integrated Housekeeping Unit" 
(IHU) and the Mode-L-transponder. 


e. Offers of participation to interested 
AMSAT groups will be released after 
availability of the full specification 
Sel 


f. Development of a compatible ground 
MODEM ans its early publication will 
be initiated in parallel with the 
Space segment development. 


ANNEX A. (Link assumptions and calcula- 


Both Mode-B and Mode-L link-scenarios have 
been investigated. Mode-B finally was 
rejected because the expected downlink- 
performance in the Z2m-Band was considered 
unsatisfactory in Japan and European 
metropolitan areas. Also the lack of 
Suitable spectrum space in the 2m-Band, the 
bulk and cost of the requrred 2m-antenna 
and the fact, that the U-transponder 

exists already, entered into the decision. 
For the sake of completeness, the links 

are also presented for Mode-B. 


Ground station assumptions: 


Mode B: Receiving (2m) Gant: +9 dBi 
Tn: 1000 k 
Transmitting (70cm) Gant: +10 dBi 
P-TxX: 5+ w 
--27 
dadBWwi 
Mode L: Receiving (70 cm) Gant: +10 dBi 
Tn: 1000 k 
Transmitting (24cm) Gant: +15 dBi 
Pox: 12 w —— 26 dBWi 


All links are to be designed with 7 dB 
margin to cover the less than perfect 
equipment to be expected in the amateur- 
environment. 


Mode-B links: 
Downlink P-Tx 
Gant S/C 


(for reference only) 
5 dBW (3W) 
3 dBi (min 
during spin) 
link at apogee -168 dB 
misc losses in 


link and S/C -3 dB 
margin -7 dB 
Gant-ground +9 dBi 
Received power 

ground Rx -161 dBW 
Pn (400bit/s) -173 dBW 
--- Eb/No 12 dB 


Mode-B uplink (Assuming 2400 Bit/s FSK) 


Gant ground 10 dBi 
P-Tx (50 W) 17 dBW 
link -177 dB 
misc. losses -3 dB 
margin -7 dB 
G-ant S/C +9 dBi 
Received power 

at S/C -151 dBW 
Pn 

(500 k,2400 b/s)-168 dBW 
--- Eb/No +17 dB 


Mode-L links (selected for RUDAK) 

Downlink P-Tx-S/C (5W) 7 dBW 
Gant-S/C 9 dBi 
Link-loss (apogee) ~177dB 
misc. losses in 


S/C and link -3 dB 
margin -7 GB 
Gant-ground +10 dBi 
Power arriving 

at ground Rx -161 dBW 
Pn 

(400 b/s,1000K) -173 dBW 
--- Eb/No +12 dB 


Uplink 


P-Tx ground (LW) 


Gant-ground 
link-loss 

misc. losses 
margin 

Gant-S/C 

Power at S/C Rx 
aaa 

(A0Ob/s, 500 k) 
—-- Eb/No 


+11 dBW 
+15 dBi 
-187 dB 
- 3 GB 

- 7 @B 
+13 dBi 
-158 dBw 


- 168 dBw 
+10 dB 
(OK with PSK) 
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A MORE WATCHFUL WATCHDOG FOR MICROCOMPUTERS 


Paul Newland, ad7i 
Post Office Box 205 


Holmdel, New Jersey 077/33 
Introduction processor, that implements a serial PN 
generator. The describing polynomial is: 

Many hardware/software watchdog 
timers consist of a software routine that Do = 1 ® Do*3 ® Do*7 
repetitively triggers a hardware 
retriggerable monostable. Lt the where "Do" means the Data-output value 
monostable ever times out, the computer for the current bit time and Do“n means 
is reset. This technique, although the Data-output value "n" bit times ago. 
useful, is not extremely reliable under The "@®" operator is the modulo-two sum 
most software/hardware insane conditions. (exclusive or) operator. 
This paper discusses an alternative 
approach that may prove to be more Every call of this routine generates 


reliable under various fault conditions. 


Discussion 

The improved system offered here 
involves the use of a_ serial pseudo- 
random number (PN) generator, implemented 
in software, and a serial pseudo-random 
number detector, implemented in hardware. 
During the execution of the system 
program, a small portion of the CPU's 


time is allocated to generating another 
bit of the PN sequence and dumping it 


(and an associated clock signal) out a 
parallel port to the hardware PN 
detector. 

When the clock lead from the 
parallel port goes high, the hardware 
checks to see if the data bit is a valid 
part of the PN sequence. If so, it does 
nothing. Tf 1k. 2S ancorrect, -1t. .resets 
the computer and doesn't allow the PN 
detector to issue another reset for a 


pre-determined period of time. This time 
delay is necessary to allow the computer 
to restart all processes and get the PN 
generator and PN detector _ back into 
synchronization. 


While this PN checking iS going on, 
additional hardware checks a tap from the 
hardware shift register to ensure that 
data is changing state occasionally. A 
failure of data change would indicate 
that either the computer is not clocking 
the external hardware or the computer is 
"fooling" the PN detector by giving it a 
degenerate PN sequence[1l]. 


Implementation 


Figure 1 shows a subroutine, written 


in Zilog mnemonics for the 280 (tm) 


4.87 


a new bit output and an associated clock 


Signal. Figure 2 shows hardware for the 
PN detector and the timing circuitry. 
Conclusion 

It is apparent from the discussion 


that any perturbation in the PN sequence 
data 


(1.e., wrong bit at the wrong time, 
stuck high or low, slow clock) will cause 
the reset signal to be issued. However, 


this "watchdog" can not protect against a 
computer malfunctioning in a way that 
causes the software-driven PN sequence to 


continue being generated. Programmers 

who might rely on a system such as this 

to protect against software "getting 

loose" should carefully consider where 

and when the PN generator routine is 

called. 

Notes 

[1] Typically, for PN detectors 
implemented using shift-registers 


and exclusive or gates, the detector 
can be fooled into thinking that the 
PN sequence received is correct if 
that sequence is either an all ones 
or all zeros pattern, depending on 
the construction of the detector. 
For this discussion, consider a 
degenerate PN sequence to be one of 
either all ones or all zeros. 


PNBIT: ¢ generate another bit of the PN sequence 


s 


LD HL, PNREG * pt to PN register 
LD A, (HL) * get contents 
CP OFFH * see if degenerate sequence 
JR NZ,PNB1O * jump if not 
XOR A * zero contents if degenerate 
PNB10: AND 444 * check taps, clear CY 
JP PO, PNB20 - jump if next bit is to be zero 
CRE s set CY to one 
PNB203 LD A, (HL) : get old contents of register 
RLA * SHLEtC. “inr néxt; bit 
LD (HL) ,A : save new register contents 
AND 1 * assume data is BO, clock is Bl 
OUT (PORT),A * set up data, clock is low 
SET 1,A : get ready to clock it 
OUT (PORT) ,A s same data, clock now high 
RET * that's “all tolks! 


FIGURE 1: SUBROUTINE FOR GENERATING A PN SEQUENCE 


To 


> O cleo ele [or Ler 


Ul, FANCTIL4t 


FIGURE 2: HARDWARE IMPLEMENTATION OF PN DETECTOR AND TIMERS 
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A FEW THOUGHTS 


ON USER VERIFICATION WITHIN A PARTY-LINE NETWORK 


Paul Newland, ad7i 
Post Office Box 205 


Holmdel, 


Abstract 


This paper presents an idea for 
verifying that a user within a party-line 
network is who he or she claims to be. 
The idea assumes that the channel is a 
party-line and that potential intruders 
will monitor authorized communications 
and may attempt to masquerade as 
authorized users. No attempt is made to 
encrypt the authorized user's data _ for 
transmission over the party-line. 


INEFOdUCELOENn 


Verification of a users identity to 


a host, historically; has been a major 
problem. At the lowest level of 
protection, many hosts require the user 
to "login" before he or she can make use 
ea any of the system's protected 
resources. Login procedures, making use 


are useful on most systems 
that a potential 
able to monitor 

and determine 


of passwords, 
because it is assumed 
intruder will not be 
easily the login process 
someone else's password. 


However, in an open system 
interconnected by unencrypted data 
communications radios (1.e., a party- 
line), the login process using passwords 
is ineffective because any casual 
observer can, by monitoring the radio 
channel, determine any other user's 
password. Also, once the user is logged 
in, there is nothing to prevent someone 


else from masquerading as the authorized 


user. 


Offered below is an alternative 
approach 156, passwords for open, 
unencrypted, communications with a_ host. 
The method assumes that the user wants 


only to give commands to the host, not to 
do file transfers. However, with a few 
embellishments, the system could be 
expanded to include file transfers. The 
system would be as follows. 
Proposal 

When the host gives a prompt to the 


telling the user that she or he may 
the prompt will 
(RN) as part of 


user, 
send it the next command, 
include a random number 


New Jersey 
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07733 


the prompt. Each time a prompt is 
transmitted, a new random number is 
included. The host then encrypts the 
last RN transmitted using the key-for- 
the-day (KEY) previously agreed to by 
both the authorized user and the host; I 
will call this "Encrypted RN" the "ERN", 
The host would then place the ERN in 
storage for safe keeping and quick 
access. The user, on receipt of the new 
RN, would also encrypt it using the KEY 
(obtaining the same ERN if the KEYS are 
the same) and would save it, COO; in a 
handy place. When the user wanted to 
issue a command to the host, it would 
give the command, as the host requires, 
Die.’ ate would include the latest 
calculated ERN. When the host receives 
the command line, it compares the ERN 
received from the user with the ERN it 
calculated from the last RN transmitted 
as part of the prompt. If they match, 
the host assumes that the user knows’ the 
correct key. Thus, by returning the 
expected ERN, the user has proved to the 
host that he or she is authorized to 
access the system. 


Vulnerabilities 

This scheme is not without its 
problems. Because the key is changed 
only once a day, the range of numbers 


used for RNs must be large to ensure that 
RNS are not repeated during the 24-hour 


period. Also, the range of RNs must be 
large enough to make the probability of 
either determining the KEY or "guessing" 


the ERN sufficiently small. A RN of 64 


bits should be large enough to overcome 
this problem. Another important 
consideration is the quality of the 
encryption technique. For Amateur Radio 
applications the DEA (that's Data 
Encryption Algorithm --_ the software 
approach te. -DES) should be suitably 
strong. 

This system is vulnerable to the 


who monitors the 
and, 


sophisticated intruder 
channel to determine the user's ERN 


before the user's packet transmission to 
the host is complete, the intruder jams 
the channel to block the user's packet 
from reaching the host. Next, the 


intruder sends his or her own packet with 
an illicit command and the ERN received 


from the user. This scenario can be 
avoided by having the user transmit the 
ERN as the last item contained in the 
data segment of the packet. 


Implementation 


How might a system such as this be 
implemented? One way would be to include 
the host's 64 bit RN in the command 
prompt using hex notation and prefacing 
the RN with a special character sequence, 
perhaps composed of an unlikely sequence 
of punctuation characters so that a 
computer could identify it. Here's an 
example where the normal host system 
prompt is the word "yes?" and is prefaced 
by the RN. 


://:0FEB23178ED83A9A yes? 


The user%S terminal emulation program 
(or, possibly, packet controller (TINC)) 
would assume that a new RN follows’ the 
escape sequence ://: and that it is in 
hex notation. It would, using the key- 
for-the-day, encrypt the RN to create an 
ERN to be saved for future use. When the 
user gives a command to the host that 
requires the transmission of the latest 
ERN, the operator would tell the terminal 
program (or, again, the INC): “Go 
substitute the ERN in place of an escape 
sequence. When the terminal program sees 
the escape sequence (such as ##), it 
would substitute the  ERN (with a 
different preface than the RN) before 
transmission. An example of a command 
line with the escape sequence might be: 


COFFEEPOT ON ## 
The terminal program would substitute the 
escape sequence (##) with the last 
calculated ERN. An example: 
COFFEEPOT ON /::/07EAF832B1A9E9A2 


A method such as this would add about 20 
characters ‘of overhead to each packet 


that contained a command for a 
"protected" host. However, if the 
protection is adequate for the 


environment, that appears to be a small 


price to pay. 


Extensions 


Again, although the idea presented 
here is simple, it should prove adequate 
protection against the more-than-average 
hostile user who might try to disrupt 
authorized communications. Other 
extensions to improve its protection 
might include calculation of a checksum 
or a more complex data reduction 
technique across all data within the 


frame and use that as another dimension 
for encryption to create the ERN[1]. 
Certainly what has been presented here is 
only a first step. I encourage others to 
pursue this and additional methods of 
providing authentication within an open, 
party-line, network. 


Notes 


[1] Private communication with Mr. 
Philip Karn, ka9q, Bell 
Communications Research. 
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ANOTHER APPLICATION NOTE DESCRIBING A LOW-POWER RS232-LIKE INTERFACE 


Paul Newland, ad7i 
Post Office Box 205 
Holmdel, New Jersey 07733 


Abstract 


A new and improved low power RS232- 
like interface is discussed. It features 
half the power consumption of the 
interface presented in a previous paper 
and uses fewer parts. 


Introduction 


In a previous paper[1l] I showed a 
method of providing a low power RS232- 
like interface. That interface met all 
the stated requirements. However, for 
those applications that do not need full 
control of the receiver slicing point and 
the hysteresis, the interface described 
here may provide an alternative solution 


with reduced parts count that is 
acceptable for most applications. As an 
additional bonus, the power supply 


current drain is even less than that of 
the original interface. 


Implementation 


The output buffers (drivers), shown 
in Figure 1, remain functionally the same 
as those of the original. The current- 
limiting resistors in series with the 
output are not absolutely necessary but 
they are shown here for completeness. 
The reference point for the drivers is no 
longer buffered by an op-amp; the 
reference is set by 2. resistors instead 
of the previous one resistor and two 
diodes. A suitable op-amp would be the 
LM358 (dual) or LM324 (quad) for speeds 
up to 1200 bps. At speeds above 1200 
bps, the slew rate of either type of op- 
amp exceeds the RS232 recommended values. 
For better performance at higher speeds, 
use a LM349 which has a_ slew rate _ five 
times faster than either the LM358 or 
LM324. 


The input buffers (receivers), as 
shown in Figure 2, are either 74C14s or 
74HC14s with the choice left to the user. 
The 74C14 requires less supply current 
and provides a larger hysteresis loop 
while the 74HC14 consumes more _ supply 
current (but less than 100 uA) and has a 
smaller hysteresis loop. 


Because both the 74C14 and 74HC14 
include clamping diodes at the input of 
each inverter section, a 100K series 
current-limiting resistor is all that is 
needed to protect against over-voltage 
input conditions. Additionally, to 
provide a default state when no signal is 
present at the receiver's input, either a 
10K pull up (to +5) or pull down (to 
ground) may also be included. 


Useful Additions 


For those who are using a_- system 
that does not have a negative supply, a 
voltage inverter capable of supplying the 
necessary current for the output buffers 
is shown in Figure 3. It is capable of 
supplying up to 50mA without significant 
ripple. 


For those who also need a_ regulated 
negative 5 volt supply, a spare section 
of an op-amp and a transistor can be used 
to provide good regulation. The resistor 
from the non-inverting input of the op- 
amp to ground is’ included so that the 
closed loop gain is greater than 5 (the 
LM349 is potentially unstable with closed 
loop gains of less than 5). 


Notes 


[1] Paul Newland, "A Low-power RS232- 
like Interface", Proceedings of the 
Third ARRL Amateur Radio Computer 


Networking Conferendepril ieee eee 
L9G4,° pp 83-04: 
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FIGURE 3 VOLTAGE INVERTER AND REGULATOR 
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The Realities of Packet Radio in the Amateur Radio Service, 


or 


Circa 1985 


How to deal with a user base. 


Harold E. Price, NK6K 


Abstract. 


The author postulates the existence of two 
major experimenter groups in amateur 
packet radio; those who experiment with 
data sent via packet radio and those who 
experiment with the way data is sent via 
packet radio. The problems .of these 
groups in the face of 5000 or more packet 
users by the time of the 5th  ARRL 
networking conference are discussed. 


Let me preface this discussion by noting 
that some of the thoughts presented here 
were the result of group discussions 
during a meeting of the ARRL Ad Hoc 
Digital Communications Committee in 1984. 
At that meeting, the major discussion was 
layer three networking. 


We have the privilege of witnessing the 
birth of a major force in amateur radio, 
one that may even have a lasting effect on 
its future. It is clear that the majority 
of technically minded junior and senior 


high school kids are now taking up 
computers as a hobby instead of amateur 
radio as in years past. If any of the 
plans being set in motion by the ARRL, 
magazines, and manufacturer's groups are 
successful in bringing new blood to 
amateur radio, the technology oriented 
newcomers will surely bring their 


computers with them. Packet radio will be 
a carrot to attract new blood. 


In 1985, 
the amount of 


we will see a large increase in 
"oress" the packet fadio 


gets. 1984 was a good year, with major 
articles in the amateur press as well as 
such non-amateur publications as ‘BYTE". 
There were also several peripheral 
mentions in PACSAT and UoSAT-11 articles 
in several areas; IEEE Institute, 
INFOWORLD, USA Today, Science, and others. 


1985 will see several more articles is 
such places as IEEE Spectrum and a special 
issue of IFEE Communications. The biggest 


increase in packet's visibility will come 
from new manufacturers entering the 
market. The number of advertising pages 


containing packet equipment will double or 
triple in the next few months. 
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The bottom line is that packet will 
continue to grow at an increasing’ rate. 
It has grown from 240 to more than 2400 
users in the last 14 months. It will at 
least double in the next year. As the 
growth of packet continues, so will the 
split between two groups, those who want 
to use the network, and those who want to 


build it. 

There are those involved in packet radio 
who want to "play" with networks. Here 
the word "play" is not used as in 


Webster's definition 2(vi) lc(2) ".... to 
behave frivolously", but rather as in 
2(vi) 2b(2) "to move or operate ina 
lively, irregular, or intermittent 
manner". Those packeteers with the right 
stuff wish to push the edges of the 
envelope. They in particular, to judge 
from conversations that spring up at all 
gatherings where networking is discussed, 
wish to experiment with routing schemes. 
Zip codes, area codes, grid squares, 
zones, directions, random chance, casting 
of bones, any number of schemes are 
waiting to be tried. 


Then there is the other group of packet 
users who wish to take the existence of a 
network for granted and get on with using 
its Emergency nets, tornado spotting, 
traffic handling, newsletter distribution, 
public service events, earthquake 
detection (presumably by detecting a drop 
in traffic from California), and other 
data utilization topics are discussed in 


user's forums. The old term "appliance 
user" doesn't apply to these folks, 
anymore than it did to an oldtime op who 


didn't draw his own wire from an ingot to 
make a cat whisker for his crystal set. 
As we move into the future, the size and 
inner complexity of the basic building 
blocks changes. A good example of this is 


the WORLI store and forward message 
system. No knowledge of the inner 
workings of the AX.25 protocol was 


required to use a INC for a building block 
to create something new, a way to get 


messages passed automatically between 
local area nets, and over HF, VHF, = and 
Oscar 10. 


Both groups need each other. A network 
must be designed and built to provide the 
services required by user community. And 


on the other hand, a network is no fun if 


it has no users: how can you get enjoyment 
out of providing an elegant bottleneck 
avoidance algorithm if no one creates 
bottlenecks in the first place? 


As the number of AX.25 TNCs grows, it 
becomes more difficult to make radical 
changes to them. The "{NC" will become a 
basic building block, it will have a set 
of assumed functions and a set place in 
the scheme of things, at least for a few 
years. As an example, when someone says 
"Grab your two meter HT and come help out 
in the marathon", there is almost no 
question that it will be compatible with 
all other two meter HTs. It will put out 
1-2 watts, be somewhere around 5 KHz 
deviation, and can be moved to any .005 
MHz channel in the 144 to 147.995 range. 
There remain a few rockbound amateurs, 
just as there are still some TAPR 1.0 roms 
and Vl VADCG boards around, but you get 
the idea. 


As it turns out, the requirement to build 
a network while not making any changes to 
the basic user TNC is a feature, not a 
bug. It forces a network design that 
isolates the inner workings of the long 
haul routing network from the general 
user. The result is a much smaller number 
of network routing devices. The smaller 
the number of devices and people involved, 
the more often changes can be made. 


Figure 1 shows the architecture of a 
network that meets the goals stated above, 
requires no changes to the basic TNC, and 
reduces the number of devices with direct 
networking capability. In this diagram, 
users, denoted by boxes containing a 2 to 
show the highest protocol layer in use, 
connect to a network access node. Several 
users can connect at a time, and more than 
one frequency can be used. They establish 
a Standard AX.25 connection with the 
device, and enter into a conversation with 
it to begin the connection process to some 
other network user. This is analogous to 
picking up a telephone handset. When you 
do SO, you are "connected" to the 
telephone network. You tell the network 
who you want to talk to by entering an 
identification code. It is not necessary 
to know how the connection is made, only 
how to access the network (pick up the 
handset) and make a connection with 
another user (dial the number). The only 
other knowledge required is recognition of 
various error messages; busy, fast busy, a 
number of "We're sorry" messages, and a 
timeout on no action. 


These Same error messages will be present 
on a packet radio network access node. 
Since a network implementation will most 
likely be staged, the initial messages 
will be quite simplistic, perhaps even the 


familiar CONNECTED and RETRY COUNT 
EXCEEDED. 
In Figure 1, the ---- connection lines are 
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the standard AX.25 protocol. Lines marked 
as can be unk other protocol, 
although most planners have agreed to use 
AX.25 as the layer two protocol with 
various higher layers added on top. The 
important point is that the exact details 
of the connections between boxes marked 
III need not be known by the majority of 
packet users. As long as the interface 
between the user and the network access 
node (the boxes labeled III) stays the 
same, the network gurus can change the 
network at will so long as connectivity 
and throughput are maintained. 


A final interesting point in figure 1 is 
the bottom left hand user. Since AX.25 is 
used for access to the network simple 
digipeating can still be used by those on 
the fringes of local area nets. MThe added 
expense of a network access node is not 
reguired for users in very low activity 
areas. 


Here is an example of the type of exchange 
that would take place between a user and 
the network access node. The actual data 


sent and received is in upper case, 
comments are in lower case and delimited 
by ft}. 


CONNECT NLA 
**k CONNECTED TO NLA 
NORTH LA NETWORK ACCESS NODE HERE. 


{ A connection is established to a 
network access node. Node names need not 
be callsigns, the node could identify 
every 10 minutes with a UI frame.1 


DI STATUS 
{The user asks for status. 
anything could be displayed here } 


Almost 


THERE ARE 5 OTHER USERS CONNECTED. 
SB LINK IS UP 

BASTLA LINK IS DOWN 

SD LINK IS UP 


{The list of connected network nodes is 
displayed. In the first networks, this 
will tell a user who he can expect to 
reach, based on his knowledge of the 
network. In the next 12 months, network 
nodes will be few in number and big in 
fanfare, so each local users will know the 
topology. A help file could be provided 
on the node for those who didn't} 


CONNECT K6XXX @SFO 
***CONNECTION ESTABLISHED. 


{A connection via some number of III boxes 
1S initiated and established.1 


Once the connection is made, a transparent 
path is established through the network 
node, and data is passed directly to 
K6XXX, who is reached through the SFO 


network node. An escape sequence similar 
to the transparent mode escape on the TAPR 
TNC or standard "smart modem” devices can 
be used to get back to the network node 
command level. 


This method of network access allows for a 
staged implementation, something that is 
extremely likely to occur in the real 
world. When the network is simple, the 
network access program can be complex, 
allowing paths to be specified explicitly. 
As the network becomes smarter in routing, 
the connect command becomes simpler, until 
it is finally CONNECT W3IWI. 


The intent here has been to quickly 
describe a way to implement a more complex 
network than is currently available while 
at the same time minimizing the impact of 
network construction on the majority of 
packet users. Many schemes are underfoot 
to provide network access devices, and the 
protocols to connect them. TAPR has 
agreed to work on the network node access 
protocol (the language used to "talk" to 
the node and get connected to someone at 
another node) Several people have 
suggested the use of the A.3/X.28/A.29 
protocols for TNC and network access node 
control. It is beyond the scope of this 
paper to go into depth on the exact access 
protocol or the network protocol itself, 
but it is hopefully not beyond the efforts 
of the amateur packet radio community. 
Let's get connected for Christmas. 
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The Implications of Traditional Operating Practices 
for Amateur Packet Network Design 


Gwyn Reedy, W1BEL 


The Florida Amateur Digital 


Communications 
Overview 
Amateur packet network design 
relies heavily upon equipment and 
procedures developed for commercial 
service. This paper urges network 
designers to examine the anticipated uses 


of the network by amateurs, and modify 
commercial practice to accommodate the 
existing amateur population. 


High Frequencies 


The HF bands are 
characterized by long distance propagation 
which varies greatly by time of day, 
season, and sunspot cycle. » Atmospheric 
noise is often severe. Tradition and the 
density of the user population prevent 


generally 


official channelization. (The variable 
nature of propagation would cause poor 
utilization of any strictly channelized 
frequency.) Standard operating frequencies 
for RTTY, slow scan TV, and other 
specialized modes approach a channel 
concept, and net operation is a method of 


channel allocation on a temporal basis. 
Only goodwill and general knowledge of 
those frequencies restrict interference. 
The lack of channelization makes possible 
the excitement and spontaneity of random 
operation which characterizes the HF 
bands. The practices of calling CO: or 
tuning for the calls of others enhance the 


variety of contacts which are possible. 
Many time-honored amateur activities such 
as DX chasing, contests, certificate 
seeking, and just plain "listening to the 
band" have flourished in the HF 
environment. However, point-to-point 
communication beyond daytime groundwave 


propagation distances on a reliable basis 
requires periodic frequency changes to 
compensate for changing propagation 
conditions. Even stations with power 
levels well beyond amateur levels must 
vary frequency in that fashion. Adaptive 
HF equipment exists that will determine 
and use the optimum frequency, but 4an 
general considerable operator skill and 
attention are required to optimize circuit 
throughput. 


Very High Frequencies and Above 


Operation on the bands above HF was 


little different from HF operation prior 
to the introduction of commercial FM 
equipment and procedures (and remains so 
on non-FM portions: -oF the bands). 


Association 


Effective communication beyond the local 
line of sight area requires knowledge of 
propagation modes and current conditions. 
A smaller population of users and reduced 
propagation distances, combined with 
generous frequency allocations, reduces 
the chances of random contacts. Much 
activity is prearranged, but activities 
such as DXing, contesting, etc. flourish. 
Reliable point-to-point contact iS easier 
to establish than on HF, using propagation 
modes which are line of sight or otherwise 
not dependent on the state of current band 
conditions. 


DOpULlarIity 2OF FM 
operation on VHF is due to a number of 
factors. Improved audio fidelity, ease of 
tuning and extension of coverage by 
repeaters are some of the obvious ones. 


The extreme 


Amateur operating procedures have been 
modified to suit the mode, and are 
considerably different from those 
described previously. Cadtameg. “CO. acs 
discouraged (but has been replaced by the 
abhorrent practice of calling "QRZ" the 
repeater). Much less random communication 


takes place and while DXing repeaters is 
fun; <2e ALS considered poor form. .2n 
populous areas. Many amateurs have 
adopted a "home repeater' which they 
monitor regularly. This provides a high 
probability of making contact with a 
particular station if his ‘home repeater' 
is accessed. I believe this ability to 
easily contact a desired station is one of 
the major factors in the popularity of FM 


operation, especially for base station 
operations. 
Message System and Telephone Bulletin 
Board Operation 

Many persons, including amateurs, 


that have personal computers are active in 


computer communication activities. The 
popular mode of Contact ToL these 
hobbyists Eon computer to computer 


communication is the landline. (The voice 
call is certainly the most common means of 
telecommunications, but hams and 
computerists enjoy using their ‘special 
equipment'), The natural two party 
limitation of conventional telephone 
connections and the single user capability 
of most personal computers have made the 


computer bulletin board system (BBS) a 
very popular method mena non-real-time 
communication among multiple participants. 


It allows a person to leave messages or 
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computer files for another without regard 
to the availability of the receiver at the 
time of transmission. This same type Of 
capability has been implemented on the 
amateur bands by RTITY, ASCII, and AMTOR 
mailboxes or message system operations 
(MSO). The capabilities of many of these 
RF accessed systems are limited by the 


transmission speed of the mode used, 
interference on the designated 
frequencies, and the restrictions of the 


character set used. 


Commercial Networks 


The hardwired networks of terminals 
that communicate with host computers in 
commercial installations have provided 
amateurs with the hardware and link level 
protocols needed for packet networking. 
The environment on a hardwired terminal 
network is fairly constant with a_ known 
quantity and location of terminals. 
Communication connectivity is assured 
within. ‘the - limits of .the cable medium. 
All devices on the cable can hear all 
other devices, given that some time lags 
will require compensation. Thus each 
terminal may be assigned a fixed unique 


identifier which will be known by the 
host. All terminals are assumed to be 
available whenever the system is 
operational. 


Packet Radio Networks 


Several factors in amateur packet 
networks are significantly different from 
commercial networks: The unpredictable 
propagation of the RF environment, the 
sporadic nature of amateur operation, and 
the uses amateurs will make of the 
network. 


In an RF environment all transmitters 
able to participate in a local network may 
not be able to hear each other. In 
addition amateur stations participate on a 
voluntary basis and cannot be assumed to 
be part of the network at any given time. 
As a result, if network connectivity is to 
be held at a high level, adaptive routing 
must be employed. This consideration is 
being satisfied in the level 3 and higher 
protocols now being developed by amateur 
network designers. 


The factors I want to emphasize are 
those based on the possible uses of the 
packet network by amateurs. Commercial 
network users send messages or electronic 
mail to other network users. The 
addressee's LAOeNntCTEICavion, as normally 
known by the sender, or his identity code 
can be found in a directory of some sort. 
There may be a general "broadcast' 
facility which allows addressing all users 
or some subset of all users. Those modes 
of operation will be very useful to 
amateur network users. There will be 
great utility in sending out a message 
addressed to another amateur by callsign 
(and perhaps some other routing 
informabion) and having the message 


delivered automatically and rapidly to the 
recipient, or at least held in his local 
area until he activates his equipment. 
But over and above the tremendous value of 
that capability, there are many enjoyable, 
traditional things that amateurs want to 
do that have no commercial equivalent. 
Chasing DX, participating in contests, 
earning certificates, and listening to 
activity in other parts of the network are 
some examples. 


Chasing DX on a packet network makes 
no sense, you say? DXing Digipeaters is 
good sport in Florida already, and just 
look at the way the Doctor DX game is 
gaining popularity. Surely if people can 
enjoy working DX with a computer program 
they will enjoy digital contacts with 
distant Stations on a packet network. 
Contests? Last Spring the first contest 
was held using OSCAR 10, a shared, limited 
resource system. By all reports it was a 
success and did not adversely affect 
"normal" operation. 


Specific ACtivities That Should Be 


Accommodated On a Packet Network 


I believe the following activities 
should be among those supported (in 
approximately this order of importance): 

1. Network control and monitoring 
LUnCtLONS « 

Ls Remote computer access/operation. 

3.  Message/Mail delivery (short 
length). 

4, File transfers (long length 
messages). 

5. Remote access of network user and 
function directories. 

6. Directional beaconing 
(broadcasting to a specific location). 

7. Monitoring network traffic at a 


remote location. 


The last three activities allow users 
to find out who is on the network = and 


perhaps make a connection. These 
activities allow the network to support 
traditional amateur operating practice 
while giving priority to the dedicated 
information transfer functions that only 


the network can provide. 


How might these capabilities be used 
by amateurs? Here are a few examples. A 


vistor in Florida for the winter wants to 
contact anyone in his hometown in the 
north. He may place a directed beacon (CQ) 


on the network that will be seen only by 
members of his home LAN. Similarly, he may 
enable a network process that will forward 
to his station any traffic addressed to his 
station on the hometown LAN. He may choose 
to monitor some portion of the activity in 
that LAN or any other LAN of his choosing. 
Limitations will have to be applied in this 
instance to reduce the load on network 
resources that would occur if all activity 
On a LAN were monitored. A desirable 
capability that substitutes processor 
loading for network loading would be 
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monitoring distant locations based on a 
keyword list. Only traffic bearing certain 
keywords (including callsigns) and related 
traffic would be forwarded to the 
monitoring station. Working network DX or 
earning the "Worked All LANS" award are 
procedural activities which become possible 
through directed beaconing and directed 
monitoring. 


summary 


Packet radio is an exciting new mode 
of communication that is gaining immense 
popularity. It builds on the popularity of 
FM operation by providing a high (and 
growing) probability of automatic message 
delivery. It combines the pleasures and 
advantages of both computer and_ radio 
communication hobbies. Its appeal and 
usefulness can be enhanced for many 
amateurs if network design provides the 
capacity and facilities for random 
operation in somewhat traditional amateur 
fashion. 
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Ax.25 NET OPERATION IN THE CONNECTED MODE 


USING THE SOFTWARE APPROACH 


Robert M. Richardson, W4UCH 
22 North Lake Drive 
Chautauqua Lake, N.Y. 14722 


ABSTRACT: 


This brief paper presents the means whereby 
an amateur radio net may be conducted using 
the AX.25 packet protocol with all stations 
in the connected mode. Use of a net 
control station connected simultaneously to 
all members of the net is described as well 
as window overlays on the video displays of 
all members of the net to display other net 
members packet information fields. 


INTRODUCTION: 


The title of this paper is an apparent 
contradiction of terms; i.e., how might one 
run a multi-station local net in the 
connected mode when a given station may be 
connected to only one station at a time? 
And, how a given station on the net 
connected only to net control, displays 
information fields from other stations on 
the net? 


Is this your paradox or conundrum of the 
year for these proceedings, coach? 


Not really, Gridley. There is no logical 
or rational reason why a given AX.25 
protocol packet station cannot be connected 


to more than one station at a time. Since 
most stations use the hardware approach 
that only allows one station to be 


connected to another single station at a 
time, most packeteers presume this to be 
the case. Using the software approach to 
AX. 25 packet one may be connected to as 
many stations simultaneously as_ desired. 

Net control can use software to match the 
stations’ on the net call letters/SSID and 
use separate number received (N/R) and 
number sent (N/S) counters appropriately. 

A window over the main menu allows net 
control to select to which net member his 
packets are addressed. 


Ok coach, so net control can be connected 
to all the stations on the net 
Simulataneuosly. Pray tell how all the 
stations on the net connected to net 
Control. can.read::each ‘other? 


Good question, Gridley. The answer is 
quite simple and an obvious one when you 
think about it. The stations on the net 
use a WINDOW overlay on their receive mode 
video display to display the TO = FROM - 
VIA call letters and info field of each 
info packet from net control and other 
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stations on the net NOT directed to them. 
This is not a "fool-proof" system since it 
assumes that all stations on the local net 
receive signal levels at least as good as 
net control. It is not meant to be used by 
stations in "fringe" areas where umpteen 
retries are necessary to get a_ single 
packet through as this would disrupt net 
operation with unacceptable time consuming 
delays. All stations on the net would have 
the capability of filtering out interfering 
packets on the net frequency. 


WINDOW SOFIWARE SUBROUTINES: 


Windows were introduced by Xerox Pare many 
years ago and later implemented in many 
popular micros such as the Tandy 
2000/1200/1000, Apple Lisa/MacIntosh, and 
IBM PC, and are truly fun and games to use 
when applied to AX.25 packet. For purposes 
of illustration, we will use the Radio 
Shack TRS-80 Models 1, 3, or 4 micros which 
all utilize the ubiquitous Z-80 
microprocessor. Even with clock rates as 
low as the 2 MHz ballpark, (1.77 MHz for 
the Model 1), it is relatively easy to 
simulate concurrent processing. Not only 
is the hand quicker than the eye, a 2 MHz 
microprocessor is many thousands of times 
quicker than the eye. 


Figure 1 is the main menu and figure 2 is 
the shift menu of the AX.25 dash 2 protocol 
software approach program. Many of the 
functions are automatically toggled ON or 
OFF, or NOW or NOT. Most input functions 
display a window over the menu and ask for 
the appropriate input in single or multiple 
window overlays. 


Figure 3 illustrates a typical video 
display on the TRS-80 in the receive mode 
using the author's software approach 
program for the AX.25 dash 2 protocol. The 
top line shows that the program: 


1. Is now in AX.25 protocol receive mode 
rather than Vancouver protocol. 


2. Has been set up for 1000 baud. 300 or 
600 baud for the HF bands may be selected 
from the shift menu if desired. 


3. The NOW FORMAT option has been toggled 
on from the menu which recognizes and 
displays all carriage returns and line 
feeds on video. 


4. The repeater function has been toggled 
ON from the main menu using WA1HDQ. 


5. The program is in the NOW connected 
mode that was selected from the main menu. 


Pressing shift 'N' displays the window 
shown in figure 4, This allows the user to 
set the window shape and size to most any 
configuration that suits the user's fancy. 
Setting the window's shape and size also 


automatically sets the program constants 
for the window's video display and 
scrolling. The window video overlay is 


entirely independent of the primary video 
display. Figures 5 and 6 illustrate two of 
the many possible window configurations the 
user may set up using shift N. 


When the NOW display other info fields in 
the now connected mode is toggled on, from 
the shift menu by pressing shift Y, the 
program displays the TO - FROM - VIA call 
letters of stations the user is not 
connected to in the window's top line, and 
the info field in the lines below, within 
the window. 


The user now has two choices that must be 
selected earlier. The first is to remove 
the window and restore the receive mode 
video display to normal by pressing ENTER. 
The second is to hold down the BREAK key 
until he or she has read the info field in 
the window, and then restore normal receive 
mode video by releasing the BREAK key. If 
he or she decides to do nothing, then the 
window is replaced by the normal receive 


mode video after a 2 1/2 second time 
delay. 

The shift menu in figure 2 offers another 
function associated with the window 


display; i.e., the window filter that may 
be toggled ON by pressing shift kK. Again, 
the user has two choices that must be 
selected earlier. Ehes First. ce-CO. filter 
out all info fields from up to 8 stations 
whose calls are input from the keyboard. 
The second is to display the info fields in 
the window from stations whose calls are 
input from the keyboard. Up to 8 stations 
calls/SSIDs may be input. 


You may have noticed in figure 2 one last 
option that concerns the window function, 
namely shift F for NOT or NOW display calls 
in the connected mode. When toggled on, 
this displays a mini-window only one line 
high with the TO - FROM - VIA calls as 
shown below. If no repeater is being used 
the VIA displays "DIRECT." 


TO WA1ABC FM WA1XYZ VIA WA1HDQ 


eee ee ee, 


The feature above is’ useful for non-net 
operation since the filter function may 
also be invoked. Forinstance, if you are 
awaiting a call from another station while 
working a station in the connected mode, he 
or she can let you know they are available 


by sending any variety of info frame, 
numbered or unnumbered. This feature 
displays the window for 1 1/2 seconds and 
then restores normal video. If you toggled 
the shift K filter function ON and input 
WAIXYZ, the only time a window is displayed 
is when WAIXYZ transmits an info frame. If 
you wish to change the response to only 
connect requests, it may be done in a few 
seconds using the edit/modify mode. Only 
one byte need be modified. 


MULTI-STATION SIMULTANEOUS CONNECTION 
FOR THE NET CONTROL STATION'S PROGRAM: 


Writing the subroutines for the multie- 
station simultaneous connection capability 
is another fun and games endeavor using the 
software approach. After the received 
frame is CRC checked in a few microseconds, 
the program progresses to test forward, and 
thence on to compare call letters. Here 
the compare subroutine can match up to 20 
calls/SSIDs that you may input from the 
keyboard or conversely, automatically 
loaded into memory during net check-in time 
when each connect request is received and 
acknowledged. 


Each call/SSID entered into the memory call 
list queue in the program also 
automatically creates separate N/R and N/S 
counters £Or each Gaskilis We have 
arbitrarily allocated enough memory for the 
net's call letters list and N/R + N/S 
counters to handle up to 20 net 
participants which seems adequate for most 
packet nets. As such, whenever you as_ net 
control are ready to transmit a packet the 
window overlay shown in figure 7 appears 
Superimposed over the main menu. Pressing 
any key from A through T directs that 
packet to the station selected in the 
window with the correct N/R and N/S count 
for that particular station. 


What if QRM or whatever causes one of the 
net members to miss a packet that net 
control received ok? Has it gone to never 
never land where scrolled off video bytes 
go? 


Of course not, Gridley. Net control has 
the option of going into memory, lighting 
the blinking cursor, placing the cursor 
over the beginning of that packet, and then 
re-transmitting it if he or she chooses to 
do so. 


CONCLUSION: 


A considerable portion of the foregoing is 
mostly a "thinking out loud" aberation of 
the author. Most of the features EXCEPT 
for the multi-station connection subroutine 
have already been written and incorporated 
into our. AX.25 dash ' 2 program that. is 
available on disk for the Model 1, 3, or 4 
(Mod 3 mode) from Richcraft as listed under 
REFERENCE (1) at the end of this paper. 


The important point we are trying to make 
is that there are many routes to achieving 
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net operation, even within the meets and 
bounds of the excellent AX.25 dash 2 
protocol. Need one change or modify the 
AX.25 dash 2 protocol for net operation? 
No, I personally think it is not necessary 
to do so. Surely, some brilliant packeteer 
with much more creative ability than the 
author will come up with a better and much 
more logical solution that does NOT require 
modifying the protocol. We have considered 
using the "star topology" and having each 
net member ACK each re-transmitted info 
packet, but the time involved with large 
number of net members precludes this rather 
pedantic approach. 


The competition EOL amateur radio 
packeteers amongst the two major suppliers 
of packet radio systems using the hardware 
approach, primarily TAPR/AEA and GLB 


Electronics is hot and heavy. We hope that 
our .old.. friend -W2EUP-of GLB: Electronics 
fame will forgive us for placing his 


software approach in hardware EPROM, in the 
hardware category, 
Our book, (1) "Packet Radio Using The 


Software Approach = AX.25 Protocol" is now 
in its 5th printing. No Gridley, we do not 
print 10,000 copies at each time, but the 
number of packeteers out there in the vast 
wasteland of computer land that are 
successfully using the software approach is 
growing by leaps and bounds. 


We have modified the AX.25 dash 2 program 
to allow the use of a number of I/O ports 
and/or memory mapped addresses available to 
the Model 1, 3, or 4TRS-80_ user. Using 
the supplied CALTRS/CMD program on disk, 
the user may customize his or her program 
with NO knowledge of assembly language 
programming. CALTRS/CMD automatically loads 
the program with the users call letters in 
the appropriate places and then asks, 
"INPUT I/O DESIRED." I/O may be specified 
for the following: 


1. A port encoder and decoder for ports 
zero through 127. 


2. The line printer I/O memory mapped 
address for the Model 1 or the line 
printer port for the Models 3 and 4 


3. The ports used by the RS-232 
interface (not the RS-232 function). 


The latter two I/O selections eliminate the 
necessity for a separate I/O port encoder 
and decoder. Only a low cost home-brew 
EXAR 2206/2211 modulator/demodulator is 
required that costs approximately $11 to 
$15 total. 


After the program is customized it is DUMP=- 
ed to disk one time only, using the DOS 
dump command. Specific dump instructions 
for TRSDOS 1.3, 2.3, NEWDOS+, & NEWDOS 1.0 
are included. The program automatically 
recognizes which Model it is in and loads 
the appropriate timing constants into the 
transmit and receive subroutines. 


ENTER OPTION DESIRED ? a 


CHANGE ADDRESSEE CALL LTRS = A WATXYZ CONNECT RFOUEST CQ = B 
NOW CONNFCTED TOCGLK = C WATXYZ DISCONINCT PRFOUFST = D 
SEND PACERTS FROM LO-MEM = E WNURY] CONNECT ACKNOWLEDGE = F 
INPUT FRAMDS/PACKET LO-MEM = G THIS IS AX.25 PROTOCOL = H 
BACKOFF DELAY TOCGLE OFF = I AUTO CONNECT TOCGLE OF = J 
NOW IN LOWER CASE MODIPY = K AUTOMODE BEACON TOGGLE OFF = L 
DISPLAY/EDIT MEMORY PAGE = M W2EUP = GIL PCOELEKE MESSAGE = N 
NOW FORMAT VIDEG TOSCLE = 0 SEND ALPHABET TROT HUSSAGE = P 
VIA WATHDO/P PEPEATER ON = Q SET OPENING FLAG LENGTH = R 
CHANGH REPEATER CALL LTRS = § INPUT/XMTE NORMAL INFO = V & T 
CLEAR NON=PCM MEM 16K-62K = U INPUT/XMIT UNNUHEB INFO = V & W 
ABORT LOW=-MEM PAK SEQUENCE = X NOT CONEK TO GOWN STATION = Y 
SHIFT MENU = 1 SET RE-TRY IN CONNECT MODE = 2 
SEND WAIT RECUEST (RNR) = 3 SEND CLEAR WAIT (RR) = 4 
Figure 1 
SHIFT MENU 2?) _ 
SEND DM DISCONNECTED MODE = A BOOT DOS READY = B 
SOND FAMP FRAML REJECT = C MOVE HI-MEM TO LOW-MEMORY = OD 
EDIT/MODIFY INSTRUCTIONS = E NOT DISPLAY CALLS IN COMNEK = F 
DG NOT TEST RCV KY“D INPUT = G ENABLE TEST RCV KYBD THPUT = RB 
SEND MOPSE I.D. = I SEND BEACUN MESSAGE MANCAL = J 
NOCT FILTER WINDOW OVERLAY = K DISPIAY LOW MEMOPY @ 16384 = £ 
DISPLAY RECY PACKS 48 53248 = M MOVE WINDOW CONNECT MODE = N 
OSCAR 16 CALL/UWANDLE LYST = O MOVE PROGRAM TC LOW MEMORY = Pp 
SAVE HI-MEM ON DISK = Q LOND PISK FILE TO HI-“n" = R 
TRANSMIT PAUD RATE SELECT = § TEST OTHER STATION STATUS = T 
CLEAR BPI-MENOFKY 53246 + = U SEND MORSF FPOM FREYRBGOARND =v 
RECEIVE AX.25 PROTOCCL = W RECV VANCOUVER NOT CGUNECT = x 
J/O GOES HFEPE NOT DI2Z@ OTHER INFO CONNECT = y 


NOTE: SPACE BAR IN RECEIVE MODE = RESEND LAST PACK 


Figure 2 


RECEIVE AX25 = 1200 BAU) -+--> NOW FORMAT RPTK ON NOW CONNECT 
The title of this paper is an apparent contradiction of terms; 
i.@., how might one run a multi-station local net in the con- 
nected mode when a given station may he connected to only one 
station ah a time? And, how a given station on the net connect- 
ed only to net control., displays information fields from other 
stations on the net? 


Is this your paradox or conundrum of the year for these proceeds 
ings coach? 


Not really, Gridley. ‘here is no logical or rational] reason why 
a given AY.25 protocol packet station cannot be connected to 
more than one station at a time. Since most stations use the 
hardware approach thet only allows one station to he connected 
to another single station at a time, most packeteers presume 
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RECEIVE AX25 = 1200 RAUN <---> NOW FORMAT RPTR ON NOW CONNECT 
The title of this paper is an apparent contradiction of terms; 
i.e., now might one run a multi-station local net in the con- 
nected node when a given station inuv be connected to only one 
Station At GQ eee a aoe ee on oo we ve oe a oe a a ae Oe me a net connect-— 
ed only to n [TO WATAGC FM WAIXY2Z VIA WA1HDO } from other 
stations on [ FRROW TO MOVE WINDOW I 

[SHIFT RIGHT/DOWN ARROW EXPAND I 
Is this your {SHIFT LEFT/UP ARROW CONTRACT ] hese proceed- 
ings coach? [BREAK RETURN TO MENU I 


Not really, Gridley. There is no logical or rational reason why 
a given AX.25 protocol packet station cannot be connected to 
more than one station at a time. Since most stations use the 
hardware approach that only allows one station to be connected 
to another single station at a time, most pncketeers presume 
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RECEIVE AX25 = 1200 BAUD +===> NOW FORMAT RPTR ON NOW CONNECT 
The title of this paper is an apparent contradiction of terms: 
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Is this your paradox or conundrum of the vear for these proceed- 
ings coach? 


Not really, Gridlcy. There is no logical or rational reason why 
a given AX.25 protocol packet station cannot be connected to 
more than one station at a time. Since most StatliunsS use the 
hardware approach that only allows one station to be connected 
to aniother single statjon at a time, most packeteers presume 


Figure 5 


4.101 
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OPTION DESIRED ? _ 


ON ae he Ep GR GD OD om Oh. Ot te oe OH oy os On a a 


CHARGS ADDRESSFE (NLT MEMBERS CHECKED IN] NNECT REQUEST CQ 
NOW CONNECTED TOG { APRIL 1, 1935 ] SCONNECT REQUEST 
SEND PACKETS FROM [WATARPC = A WA1TKLM =* K) NNECT ACKNOWLEDGE 
INPUT PRAMFS/P..CK [WA1BCD = B WAILMN = L) x. 25 PROTOCOL 
BACKOFF BELAY TOG [IVICDE = 
NOW TIJ UPPF CASE (WAIDEF = D WAINOP 
DISPIAY/EDIT MENO [WA1EFG = 

NOW FORMAT VIDIO [WATFGH = F WAIPCR 
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Figure 7 
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COMPUTER NETWORKING IN JAPAN 1985 # ONWARDS 


AND HOW BILL GATES' 


(MICROSOFT) CREATED 


THE FAR EAST & PACIFIC MSX STANDARD 


Robert M. Richardson, W4UCH 
22 North Lake Drive 
Chautauqua Lake, N.Y. 14722 


ABSTRACT: 


The evolution, development, and imple- 
mentation of the Microsoft MSX operating 
system in nearly 2 dozen models of micro- 
computers now being manufactured in the Far 
East and Pacific (FEP) is discussed along 
with their impact on packet radio on the 
amateur bands primarily in Japan, for the 
1985 = onwards, time frame. 


INTRODUCTION: 


Gridley, here is your trivia question of 
the week. Why is Apple to microcomputer 
Similar to Microsoft to software? 


Gotcha coach. They are both the biggest in 
their respective fields. 


Not really, Gridley. IBM's dividends 
exceed Apple's 2 billion dollar annual 
sales. ' hbrthermore, there are a number of 
software houses that are as large or larger 
than Microsoft% $200 million annual sales. 
Try again, Gridley. Think back to the 1975 
- 1976 era of yesteryear tall masked man. 


Aha, you gave me a clue, coach. Both firms 
were started by rather young computer buffs 
working in garages, dormitory rooms, or the 
acne. 

Right you are, Gridley. Steve Wozniak and 
Steve Jobs at Apple, and Bill Gates and 
Paul Allen at Microsoft were the leading 
perpetrators «= founders, of these two out- 
standing firms. 


So what does that have to do with the MSX 
missile program, coach? 


Absolutely nothing, Gridley. The ‘MS' 
stands for Microsoft and the 'X' stands for 
the Microsoft extended Basic interpreter. 
MSX is what this short paper is all about, 
plus its impact on amateur packet radio in 


the Far East and Pacific basin, especially 
in Japan. 

BY 1979, Microsoft's BASIC interpreter, 
first written by Gates and Allen circa 
1975/1976, had become the defacto world 
standard BASIC, and still is today, 
Microsoft's achievements are really too 
numerous to mention, but two items 


particularly standout. The first and most 
obvious is MS DOS, the fundamental PC DOS 
disk operating system for the IBM PC. The 


The second and not guite so obvious 
achievement was the Microsoft "Softcard" 
that turned the Apple II‘ into a real honest 


tO goodness modern day micro by 
substituting the ubiquitous Zilog 2Z-80 
microprocessor gona the cheapy 6502 
microprocessor with its very limited 


instruction set and minimal registers. 


In the early 1980's, Bill Gates' foresight 
& precognition again came to the fore and 
Microsoft, called ASCII Microsoft Ltd. in 
Japan, developed the MSX operating system 
for microcomputers that utilize the Zilog 
Z-80A microprocesor (or its licensed 
counterparts manufactured in Japan). The 
idea here was an extremely sound one; i1.e., 
any microcomputer using the licensed MSX 
operating system would have complete 
software program compatibily with any other 


microcomputer using the licensed MSX 
operating system. Beyond software 
compatibility, a further goal was to have 


completely interchangeable peripherals. 


In addition to the usual line printer, 
light pen, etc., peripherals, they also 
include stereo sound, video disk, and video 
cassette, plus optional growth capability 
via the MSX DOS (disk operating system) to 
use the new 360K byte (formatted) 3 1/2" 
floppy disks now being manufactured in 
Japan. Microsoft provides the MSX disk 
operating system on a chip which is built 
into the floppy disk drive adaptor. 


FUNDAMENTAL MSX OPERATING SYSTEM SPECS: 


Microprocessor : Z-80A 4 MHz clock 
MSX ROM : 32K bytes standard 

MSX RAM : 32K average = up to 64K 
Video control : Texas Instr. TMS-9918A 
Text display : 32 characters X 24 lines 
Graphic display : 192 X 256 dots 16 colors 
Sound generator : General Instr. AY-3-8910 
Audio range :8 octaves, 3 tone chord 
Peripheral chip : Intel 18255 

Line printer : Centronics parallel port 
Cassette : 1200 bps low 2400 bps hi 


This sure looks like a fun and games 
specification to me! 


Yes, and no,’ Gridley. The MSX spec is 
aimed at the universal “home computer" 
market. Notice we did not say "personal 
computer" market as there is a_ substantial 


difference between the two. It 1S obvious 
from the MSX text display specs that it is 
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designed to work with a_ standard home 
television set serving as the video display 
as 32 characters by 24 lines is the maximum 
that a standard home TV set's video 
bandwidth can handle. Video output is to 
the TV set's video input or via an optional 
TV channel RF modulator. Analog Red Green 
Blue (RGB) output is another option. 


It is worth noting that the majority of MSX 
micros offer RAM expansion to 64K bytes, so 
undoubtedly virtually all of them utilize 
bank memory switching between ROM and RAM. 
The ROM may be plugged into the MSX 
cartridge slots, one or more, on all MSX 
micros. You should also note that 
virtually none of the MSX micros include or 
offer the RS-232 serial interface that the 
hardware variety of packet radio buff is so 
fond of using. 


Another fascinating aspect of the MSX 
specification is what ASCII Microsoft 


Ltd. Mr. Kazuhiko Nishi terms the "MSX 
Engine." This fabulous chip, soon to be 
manufactured by Toshiba combines the 
functions of the Z-80A microprocessor, the 


TMS 9918A video control, 18255 peripheral 
controller, and AY-3-8910 sound generator 
ALL on a single chip. The price tag is 
expected to be under $10 when mass 
procuction gets rolling. 


MSX MICROCOMPUTER MANUFACTURERS : 


Canon (Japan) 
General (Japan) 
Kyocera (Japan) 
Victor (Japan) 
Yamaha Nippon Gakki (Japan ) 
Mitsubishi Electric (Japan ) 
Sony (Japan ) 
Pioneer Electronic (Japan ) 
Matsushita Electric (Japan ) 
Toshiba (Japan ) 
Hitachi (Japan ) 
Fujitsu (Japan) 
sanyo Electric (Japan) 
Samsung Electronics (S. Korea) 
Gold Star (S. Korea) 
Daewoo Electronics (S. Korea) 
Limco Products (Singapore) 
Oric Electronic (Singapore) 
Command Module (Hong Kong) 
Radofin Electronics (Hong Kong) 
NOTE: 


Another player in the MSX game: 
Philips Eindhoven (Holland) 
(UK, France, West Germany soon?) 


Prices in US $ for MSX microcomputers vary 
from a low of about $150 up to a high of 
$380, depending upon options. The 360K 
byte 3 1/2" disk drives from Sony and 
Toshiba retail for an additional $330 which 
will surely decrease as volume goes up. 
Most of the above manufacturers, except 
Yamaha's Musical Instruments Division, do 
NOT plan to market their MSX micros in the 
U.S. Their major thrust will be in Europe 
and Japan, with a few targeting the Middle 
East with Arabic keyboards. 


At the end of 1984 there were about 1/2 
million MSX micros in use in Japan with the 
1985 - 1986 forecast in the 1to 2 million 
ballpark for Japan ALONE. 


Ok coach, I am impressed. Now, let's get 
on with the packet story line which is what 
this discussion is supposed to be about. 


Sorry Gridley, I got carried away by all 
these fascinating facts and figures. 


JAPANESE RADIO AMATEURS 600,000 PLUS: 
That's another impressive figure! 


Yes indeed Gridley, especially when one 
considers that the first Japanese AMSAT 
bird with AX.25 packet capability is going 
to be launched in 1986, plus a number of 
forward thinking Japanese amateurs are 
already planning a number of AX.25 protocol 
packet repeaters for installation beginning 
the summer of 1985. 


Hmmmmmmmnm ? Standard 32K plug-in-able ROM? 
No RS-232? Common standard keyboards? 
Common standard video displays? I have a 
great idea for the software approach to 
packet, coach! 


Hold your horses, Gridley. We are working 
on the first dedicated packet ROM cartridge 
for. an MSX “micro. for our Far East © Pacific 
distributor in Tokyo. Our 30 page 
instruction booklet will be translated into 
Japanese shortly. 


o-l=L-E-N-C-Es 


I stole your thunder, Gridley. Here 


sorry 
this little joy 


are the rough details of 
and delight: 


- End user price of the MSX packet 
cartridge will be the equivalent of 
$80 U.S. 


- Requires 32K RAM which most all MSX 
micros have or exceed. 


- The 1200 baud MSX cartridge has AFSK 
output to the user's transmitter via a 
cable and plug, a cable and plug for 
audio input from the user's receiver, 
and a cable and plug to the user's T/R 
relay. 


- The 300 baud MSX cartridge is identical 
to the one above except the I/O is for 
200 Hz shift on the HF bands. 


- All plugs are configured for the Kene- 
wood, ICOM, and Yaesu amateur trans- 
ceivers. 


«- All features of the Richcraft dash 2 
AX.25 protocol software approach are 
included. Instead of 2 menus, 4 menus 
are provided due to the 32 characters 
per line text display. Windows are 
provided over menus as well as on the 
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receive mode video display when toggled 
ON. 


- Only half of the 32K available ROM is 
is used for the packet program and 
ancillary subroutines such as keyboard 
decoding, video display/control, etc. 
As such, there is plenty of room avail- 
able for level 3/layer 3 implementation 
next year. 


-~ The 32K RAM is partitioned into the 
following segments: 12K for processed 
received info frame storage, 12K for 
storing long files to be transmitted, 
4K for packet assembly and disassembly, 
and 4K for variable storage. Those MSX 
micros with 64K RAM memory use the extra 
memory for expanded receive and transmit 
storage. 


- Packet in living color is available 
if desired. Only the most frustrated 
art major would find the 16 colors 
inadequate. Zooming windows, color 
identification of TO «= FROM = VIA and 
all sorts of Walt Disney animation is 
quite easy to accomplish. 

When will we see the first MSX micros in 

the U.S. ? 


enroute if not already here 
Gridley, but do not look for them in your 
local computer wonderland store. MThe first 
MSX manufacturer that has stated publicly 
that they will give the U.S. market a try, 
is Yamaha who will distribute them through 
its Musical Instruments Division. Best 
visit your local music store if you want to 
see the Yamaha model YIS-503. Pioneer also 
plans to test the U.S. market later in 1985 
with their model PX-7. 


They are 


CONCLUSION: 


AX.25 protocol packet activity is about to 
explode in Japan. The Microsoft MSX 
specifications are truly ideal for the 
Richcraft software approach to packet radio 
and allow operation at any baud rate from 
300 on up through 2400 baud at extremely 
low cost. Just plug in an MSX packet 
cartridge and you are "on the air." 


The author's non April 1, 1985 prediction: 


"By 1987 there will be as many or more 
AX. 25 packet amateur radio stations in 


Japan as in the rest of the world 
combined." 

Many U.S. amateur packet radio buffs will 
pooh pooh the MSX micro spec. Undoubtedly 


these are the same experts who pooh poohed 
Japanese designed and manufactured 
automobiles for the U.S. market a number of 
years ago, 
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Activity report of PARNET 


Takemi Yamazaki, Masahiro Takeda, Motokazu Kashida, 
Masa — aki Yonezawa, and Tadanori Harada 


Abstract 


We have been studying and working on 

digital communications in ham radio for the 
past year. The group activities are discribed in 
this paper. 
In section one, there are member’s profiles, 
groups aim/policy and results of our 
investigations. In section two, the hardware of 
the prototype is described. In section three, the 
software descriptions and in section four, 
prospect in the future is written. 


Introduction 


Members of PARNET (Packet Amateur 
Radio Network) are JIIBXM, JA3FGN, 
JAIMIR, JHIUWU and JELWAZ. Members 
are either electronics engineers, or specialists 
of software and hardware. 


Objectives 


We gathered to achieve common goals of 
the project. Those are: 


A)to study the method to connect our 
transceivers with our personal computers. 

B) to establish a computer network through 
ham radio. 

C) to construct a central station for the net — 
control which has many useful functions with 
large capacity of memories. 

D) to connect our central station to other 
data networks, JAS- 1 Satellite repeater, AO 
— 10 and so on. 

E) to provide the cental station as an open 
repeater for world-wide Ham stations. 

F) to propose a new packet protocol which 
fits to the circumstances in JA, and to the 
mobile radio, if possible. 


Current status 


First, several modulation alternatives 
were investigated, and frequency spectrum was 
checked by using a computer. And we get the 
result that the FSK modulated by base- band 
is good for high baud rate. But it is not easy for 
a user to reconstruct or to buy a tansceiver for 
the special purpose. So we made a plan to use 
the AFSK modulation. 


We consider that AX.25 is the standard 
to connect the worldwide network via a 
satellite repeater. So we select AX.25 as a 
protocol to hold a compatibility at the first step, 
We chose a TAPR-TNC as a compatibility 


checker and our software is under development 
through actual data exchange between ours 
and TAPR’s. 


On the other hand, we believe that ‘easy 
to make’ is important for a hardware. So our 
hardware is so different from TAPR’s and has 
few tuning point. 


We decided that our TNC supports the 
lower level protocols only. Higher level 
protocols (level 3 and above) should be 
handled by personal computers. And the 
software is designed to be able to change the 
structure to support yet another protocol which 
matches the conditions in JA and to the mobile 
radio in future. 


Figure 1 — figure 4 show the result of the 
calculations of the power spectrum in 1200 
baud AFSK modulation. 3 dashed lines in each 
figure indicates the bandwidth which covers 
90%, 95% and 99% of power spectrum, 
respectively. FIG.3 and 4. show the power 
spectrum of Bell 202 and MSK respectively. 
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Hardware 


Design goal of our prototype hardware 
was to simplify the circuit, to make it a small 
single board, and to reduce tuning points. 


A block diagram is shown in Figure.5 


where; 
CPU: Intel Z80A CLOCK 2.46 
(4.915212) MHz. 


RAM: 6116 X8 6 K Bytes (including 
battery backed up 
RAM 2 KB). 

ROM: 2764 X2 16 K Bytes. 


SERIAL PORT: 18251 
For VDT or 
Computer. 
HDLC CONTROLLER: 18273 
Digital PLL circuit on 
chip. 
MODEM: Am7910Programable 
universal MODEM. 
Genarate baudot rate 
clock. 


PTM: 18253 


The firmware on ROM controls these LSIs 
and electrical switches. We planned that the 
TNC system handles Physical layer and Data 
Link layer. The Network layer and higher 
layers are handled by a computer. (See 
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Figure 2 Power Spectrum 
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Figure 3 Power Spectrum 
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Figure 4 Power Spectrum 
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Figure.6) Z—80A processor has enough 
performance to deal with data and to control 
the circuit for handling Level 1 and Level 2. 
RAM area is 6 KB and it is enough to store 
several packets. Back -up circuit using Ni — cd 
battery is available to keep parameters set up 
by a user in static RAMS. SERIAL PORT uses 
RS-232C standard which is very popular so 
that the software for interface between the 
TNC and Computer is simplified. HDLC 
CONTROL Section is characterized by its 
Digital Phase Locked Loop (DPLL) circuit . 
There are hundreds of bits in a packet, so 
unsynchronized clock causes fatal receiving 
error. DPLL circuit regenerates clock from 
receiving data. So it is able to communicate on 
bit oriented data stream without a clock line. 
MODEM block is wonderful. There is no 
tuning point. It generates phase continuous 
AFSK audio signals, and meets to BELL 
103/113/108, BELL 202, CCITT V.21 and 
CCITT V.23. To meet TAPR TNC, it is 
programmed to BELL 202. 


Software in PARNET TNC 
Software architecture 


TNC has to execute the following jobs 
simultaneously. 


Figure 5 Block diagram of TNC 


Computer/ 


VDT 


A) Sequence control block: transfers strings 
(send — data), converses with the terminal, and 
controls the internal state. 

B) Protocol control block: controls the packet 
header, manages the packet sequence number, 
and controls the transceiver PTT. 


Figure 6 Layer handling 


reference model 
| 
L5 


COMPUTER 


In case of the fact that a single CPU executes 
more than one task simultaneously, ‘REAL 
TIME MONITOR’ are often used as the 
operating system. But on the development of 
our TNC, we made the simple language for 
multi- task execution, not to get down the 
memory availability, and we use it in order to 
program the PROTOCOL CONTROL BLOCK. 


This language manages the sequence 
number (label) like BASIC. The control of the 
routine is always interrupted at the beginning 
line of the loop, and the control transfer among 
concurrent procedures is occurred, to avoid 
possible dead —lock, which causes the violation 
of the correct sequence control. 


The program is converted into language 


C using a preprocessor which is also written 
with language C. Since the SEQUENCE 
CONTROL BLOCK can be programmed just 
as the main routine, the efficient programming 
can be expected. 


We use an NEC PC -8000 system and C 
compiler on the CP/M for the development of 
the software. 


TNC Mode 


PARNET TNC has two modes. One is the 
conversation mode on which we can converse 
with other pepole by using ASCII characters 
just like RTTY, and the TNC can be controlled 
by human readable command. The other is the 
binary mode where binary files can be 
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transferred. In the binary mode, the 
conversation and control are achieved by 
using ESCAPE SEQUENCES, and it is 
available for a computer to control the internal 
state sequences. 


Layer assiqnment 


The repeater addresses are set in each 
packet header and included in the layer—2 on 
AX.25 recommendation. But Japanese 
authority allows no digipeater at the present 
time. So the function of the digipeater address 
specification is not required in JA. Moreover, 
even if the digipeater was allowed, it should be 
required that the data flow path information 
must be allocated in level 3. It is the role of net 
work layer rather than link layer to control 
message forwarding. This decision gives us 
another advantage of realizing shorter packet 
during the test operation. The reason why we 
want to reduce the packet length is that the 
data communication is always (much 
frequently !!) disturbed by some stupid ham 
radio guys. 


On this layer assignment, the data flow 
path can be alsoinstructed by any user witha 
high level algorithm in the host computer. 


Examination in the future 


Our major activities, so far, were 
concentrated on realizing a TNC which is 
compatible with AX.25. We have completed a 
TNC which could be utilized to practical use. 
We are now planing to examine the various 
applications of the TNC to upper layers and 
also to look for a method of high—speed 
transmission, accompanied with good quality. 


The items which we are looking at are as 
follows. 


To desian and build a computer for 
center station. 


The idea of the computer is to have the 
main memory with the capacity of 1 to 2 M 
Bytes and a hard disc device with more than 20 
M Bytes. We would like to use UNIX as OS and 
release this facility to common users. 


To utilize error correction code 


We would like to test the error rate in 
both with ECC and without ECC statistically, 
and if the difference is significant, examine the 
potential of realization of ECC with current 
TNC. We consider that ECC is necessary to 
relieve the interference in Japan (ie, 
jamming). We are looking at the realization by 
implementing micro —programming and if it 
is not feasible, we may have to introduce dual 
processor system. 


To examine modulatina methods to 


enable high — speed transmission 


We want to realize the transmission at 12 
Kbps to achieve high-— efficiency and high— 
fidelity and implement a low pass filter with a 
duobinary square-root characteristics to 
reduce the out —of— band radiation, and the 
modulator has 4 transmission level. The 
demodulator will be a discriminator which is 
compatible with an current I'M receiver. 
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AMATEUR PACKET RADIO IN IARU REGION 3* 


Paul L. Rinaldo, W4RI 
American Radio Relay League 


Newington, 


INTRODUCTION 


About @MMradio amateurs throughout 
the world are now equipped for packet 
radio, and the number is more than dou- 
bling each year. Amateur packet radio was 
made possible by the introduction of the 
personal computer around 1975 and experi- 
mentation by radio amateurs since 1978. 
The common goal of these experimenters is 
to build a global network that will enable 
personal computers to exchange data rapid- 
ly and without errors. The network not 
only will handle conversational QSOs but 
will support many new services such as 
transfer of record messages, access to 
electronic data bases, transmission of 
videotex and facsimile images, and digi- 
tized speech. Packet radio is not simply 
a high-tech replacement for radioteletype; 
it is an automatic and reliable method of 
transmitting any digital information in 
SOLE.) DIESE S- 


While amateur packet radio had its 
start in the North America, it has now 
taken root in many countries throughout 
the world. In the Asia and Pacific 
areas, there is notable amateur packet- 
radio development in Australia, Japan and 
New Zealand. There are early signs that 
the Japanese Amateur Radio industry is 
looking very seriously at new products 
involving packet radio. Not only can they 
sell packet-radio products to amateurs 
worldwide, but there are many commercial 
and governmental applications for a full 
product line. In the United States, there 
already has been some spinoff of amateur 
packet radio into other radio services. 
Some current examples are: (a) U.S. For- 
estry Service use between personal compu- 
ters in National Parks, (b) data communi- 
cations with military severe-weather- 
Surveillance aircraft, and (c) mobile 
communications with a large fleet of over- 
night courier vehicles. 


Without a doubt, amateur packet radio 
is here and is here to stay. As in any 
new technology, it is not possible to 
predict its future twists and turns, or 
even its ultimate shape. Military or 
commercial projects can be organized in a 
top-down manner with clear objectives, 


*This paper was prepared for presentation 
at the International Amateur Radio Union 
Region 3Conference in Auckland, New 
Zealand, November 13-17, 1985. As it con- 
tains information of interest to other 
areas, it is printed herein. 
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financial control and technical direction. 
We amateurs do not have the benefit of a 
well-funded central authority to develop a 
network. Instead, we have individuals and 
groups with a great freedom of action and 
diversity operating with funds of piggy- 
bank proportions. The Amateur Satellite 
program was perhaps the first example of 
how amateurs learned cooperation and divi- 
Sion of labor in a complex technical pro- 
gram that would serve all radio amateurs. 
Building a global packet-radio network 
will require the same synergism -- and 
more. We need the specialists to devise 
new protocols, software and hardware. We 
also need the organizers, facilitators and 
entrepreneurs to apply their efforts to 
the main stream without stifling innova- 
tion. 


National Societies have a large stake 
in the outcome of packet-radio development 
in Region 3. Societies can help create an 
environment in which creative amateurs can 
flourish. Finding precious human and 
material resources 1S another role. 
Clearing away obstacles to packet radio in 
radio regulations is an important goal for 
National Societies and the IARU. Coopera- 
tion in international amateur packet-radio 
standards is another essential task for 
National Societies to ensure that the 
network is interoperable. 


CREATING AN ENVIRONMENT FOR PACKET RADIO 
EXPERIMENTATION 


Many countries in Region 3 already 
have centers of excellence -- areas with 
Amateur Radio clubs with technical inter- 
ests, radio amateurs in the science and 
engineering professions, computers, labo- 
ratories, and universities. Chances are 
that amateur packet radio will sprout on 
its own in these areas. But for that to 
happen, there has to be some knowledge 
that packet radio exists and an individual 
who will be a spark plug or initiator. 
National Society membership journals, com- 
mercial magazines and newsletters can 
spread the word of packet radio's exis- 
tence. In our experience, however, it 
takes a personal presentation by a packet- 
radio enthusiast to plant the seed. A 
demonstration of a working packet-radio 
system is needed by most amateurs for them 
to comprehend how it works and what it can 
do. A knowledgeable person can answer 
questions and clear up any misconceptions. 
Our experience is that this is sufficient 
to generate interest in these centers of 
excellence. Actually making packet radio 
happen in such areas usually depends on 
putting a packet-radio repeater (digipea- 


ter) on the air and getting at least two 
amateurs to start uSing it. From there, 
packet radio seems to be established and 
capable of further growth. 


For packet radio to get started in 
high-tech areas, there must be continual 
access to equipment, software, and other 
system support. These things are readily 
available in the United States and are 
becomming available in other countries. 
In some countries, importing is a problem, 
and developing domestic sources may be 
possible. For example, you may wish to 
investigate local production of packet- 
radio eguipment printed-circuit boards 
under license of a U.S. manufacturer. 
Some countries have the resources to de- 
veloptheir own equipment; however, this 
is not @ trivial. task. 


There will also be a continual need 
for the latest information about packet 
radio because it is rapidly developing. 
ARRL Headquarters keeps fully informed 
about packet-radio activities in North 
America and elsewhere, and is willing to 
share this information on a timely basis 
with other National Societies. ARRL pub- 
lications (Gateway, QST, QEX and the Hand- 
book) are the vehicles we regularly use to 
disseminate information about packet 
radio. In addition, we offer the pro- 
ceedings of past ARRL Amateur Radio Compu- 
ter Networking Conferences -- some 76 
technical papers written by amateurs. 


So far, I have covered only the sim- 
pler problem of how to get packet radio 
started in an area with essentially the 
right conditions. What can be done where 
the environment is not particularly condu- 
cive? It may be a long process and might 
have to waituntilthe day of mass availa- 
bility of packet-radio systems. Perhaps 
the major manufacturers will eventually 
reduce the packet-radio controller to a 
Single integrated circuit and make it an 
organic part of all-mode transceivers. 
Butwhatcan we do in the short term? The 
answer could lie in the centers-of-excel- 
lence concepts outlined above and encou- 
raging such centers to set up networks 
between them, both nationally and interna- 
tionally. Maybe that will attract others. 
"Packeteers" in the United States wishing 
to link from one city to another have been 
able to recruit another breed of ham -- 
the fellow who sees his role in life as 
putting VHF repeaters on the air. News- 
letter editors, club officers and other 
amateurs initially not the least interest- 
ed in packet radio similarly can be en- 
ticed to help. We haven't gotten the 
attention of many contesters, but that too 
will come in time. My point is that by 
division of labor and recruiting people 
with varied backgrounds, packet radio can 
get started with only a few "“high- 


teckies." 


Another possibility is to take advan- 


tage of the fact, as the saying goes, that 
necessity is the mother of invention. In 
those parts of the world where radio ama- 
teurs play a role in disaster communica- 
tions, there already has been considerable 
interest expressed in packet radio -- and 
some significant use of the method, parti- 
cularly in California’. A marriage of 
technically inclined amateurs with those 
having a need or desire to improve Amateur 
Radio disaster communications can yield 
enormous benefits. 


RADIO REGULATIONS 


Radio amateurs in North America 
should consider themselves fortunate that 
their regulatory agencies (Department of 
Communications in Canada, and Federal 
Communications Commission in the United 
States) led the way by writing packet 
radio provisions in the rules. In the 
Canadian instance, in 1978, the DOC deli- 
berately set out to foster packet radio, 
laid down specific rules for it, and 
created a Digital Amateur license class. 
In the U.S., the FCC took notice of the 
Canadian action and introduced both the 
ASCII code and packet radio into the regu- 
lations as the saving grace of an embat- 
tled inguiry already underway to control 
emissions by bandwidth rather than mode. 


This 1S not to say that U.S. and 
Canadian radio rules are without problems 
with respect to packet radio. However, in 
both countries, the administrations took 
the initiative and have remained receptive 
to regulatory changes to encourage experi- 
mentation. If such receptivity to experi- 
mentation is lacking, the National Society 
should consider ways of working with regu- 
latory officials to improve the climate. 
FCC officials have responded favorably to 
in-person briefings on, and demonstrations 
of, new technology. All regulatory offi- 
Cials having approving authority need to 
know what packet radio is, its potential, 
and its impact on others who share the 
spectrum. More fundamentally, they should 
understand how Amateur Radio experimenta- 
tion benefits the general public and the 
communications industry. 


Concerns 


In addition to an appreciation of 
amateur experimentation and the benefits 
of packet radio, there are several con- 
cerns that need to be satisfied. 


A major concern is that the regulato- 
ry agency may not be able to monitor 
packet-radio transmissions if and when 
they wish to. In dealing with this issue, 
we have pointed out that it is impossible 
for the government to monitor all Amateur 
Radio transmissions anyway because of 
propagation. Thus the propriety of Ama- 
teur Radio transmissions depends largely 
upon a trust that licensed amateurs will 
act responsibly and obey the law. The 


Amateur Service takes pride in its ability 
to police itself. Confirmation of this 
bond of trust between amateurs and the 
government should do much to address the 
concerns that packet radio would be mis- 
used in the Amateur Service. Neverthe- 
less, the regulatory agency needs the 
technical tools to monitor when it needs 
to. This can be satisfied by a packet- 
radio controller and a low-cost personal 
computer. The National Society can help 
by specifying exactly what is needed, 
facilitating procurement, and assisting in 
the initial installation if needed. Per- 
haps this can be obviated by getting one 
licensed enforcement official personally 
interested in packet radio to the degree 
of getting on the air. In certain coun- 
tries, it may suffice to ensure that ama- 
teurs having the necessary qualifications 
and the full trust of their government 
have the ability to monitor packet trans- 
missions.* 


Even if it were technically possible 
to monitor every packet-radio transmis-— 
Sion, there is the matter of volume. In 
the early stages of packet-radio develop- 
ment when volumes are low, it may be pos- 
Sible to closely monitor most or all 
transmissions within radio range. As 
volumes pick up, as they have in the U.S., 
human ability to physically read the 
transmissions is exceeded. It would be a 
full-time job for one person to scan traf- 
fic from one fully loaded packet-radio 
channel operating at 1200 bits per second. 
For an individual responsible for a digi- 
peater, this poses a problem of how to 
prevent transmission of communications 
that are prohibited by the rules. 


o An ultraconservative approach 
would be to have the digipeater trustee 
preview each and every packet prior to 
retransmission. That's obviously imprac- 
tical and not considered necessary for 
voice repeaters; why burden a new techno- 
logy with such a restriction? 


o Another "cure" often sugges- 
ted is to add a software "filter" that 
will screen out prohibited material. Some 
telephone-line bulletin-boards operators 
have gone so far as to develop a list of 
vulgar words. This has several pitfalls. 
There is a potential for embarrassment if 
the word list is revealed. Experience 
shows that it is impossible to think of 
every possible word or phrase that could 


* For many years ARRL has had Official 
Observers. In 1984 an agreement was 
reached between the ARRL and FCC to estab- 
lish an Amateur Auxiliary or Volunteer 
Monitoring Program. The agreement covers 
two classes of volunteer monitoring sta- 
tions: 1) the station-level monitor or 
individual Official Observer, and 2) a 
handful of Regional Monitoring Stations. 


be improper, especially if one is trying 
to rule out indecent language and other 
types of traffic (such as business mes- 
sages). The "filter" ends up so all- 
encompassing that everyday communication 
between amateurs may not get through. Add 
to this: the ebilaty of individuals to 
outsmart the "filter" by using only words 
that are not on the list. 


0 The third approach is one 
based almost entirely on trust and peer 
pressure of the amateurs using the net- 
work. The trust aspect rests on the fact 
that amateurs are licensed, worked hard 
for it, and would not like to lose it by 
violating the rules. with a highly auto- 
mated network, not too many amateurs will 
be monitoring each transmission, but those 
in range can do so. 


Whether or not there is anyone moni- 
toring, the packet still must be addressed 
to another amateur station; the addressee 
can be expected to advise the originator 
that a communication iS improper. Opera- 
tors of computer-based message systems 
(CBMSs), often called bulletin boards or 
mail boxes, can program their systems to 
prevent retransmission of messages not 
screened. Or, a more-liberal approach 
would be for the operator periodically to 
scan messages already stored, kill impro- 
per messages and advise the originator why 
the message was purged. This whole 
process can be backed up by a modest capa- 
bility for volunteer monitors and govern- 
mental monitors to conduct spot checks and 
respond to complaints when they occur. 


Signaling Rates and Spectrum Occupancy 


About the only signaling rates in use 
at present are 300 and 1200 bauds. The 
lower speed is used on below 28 MHz; the 
higher one on VHF and UHF. If freedom to 
experiment were the only consideration, 
there should be no speed limit on trans- 
mission of data. But, of course, packet 
radio must share the spectrum with other 
users, so there should be some upper bound 
on the occupied bandwidth -- either by 
regulation or "gentlemen's agreement." 


Unfortunately, it is not possible to 
equate data rate with bandwidth. Band- 
width is determined by several factors: 


o data rate (in bits per second 
or bit/s) 


0 the modulation technique 
(e.g., FSR, BPSK) 


o filtering and nonlinearities 
after filtering. 


In the modulation systems used thus 
far, one bit is equal to one symbol trans- 
mitted (1 baud = 1 bit/s), thus bandwidth 
is proportional to data rate. However, as 
the spectrum becomes more occupied and 


modems become more sophisticated, there 
will be a trend toward so-called m-ary 
modulation systems. In such systems, it 
is possible to encode 2, 4, 8, or more 
bits into a single transmitted symbol by 
using various phase and amplitude combina- 
tions. It 1S important that radio regula- 
tions provide for m-ary modulation sys- 
tems, for both experimentation and future 
growth of packet radio. 


In the regulatory proceeding that set 
speed limits for digital communication, 
the FCC proposed defining speed in bit/s. 
Commenting amateurs pointed out that this 
would have locked out the use of m-ary 
modulation and would have been counter to 
spectrum conservation. As a result, where 
speed iS mentioned in the rules, it is 
specified in bauds (symbols per second). 
Thus there is a direct relationship be- 
tween the modulation rate in bauds and 
bandwidth. The FCC used both modulation 
rate and bandwidth, as summarized below: 


ITA2 Any digital 

AMTOR codes, only 
Frequencies ASCIT = above 50 MHZ 
<28 MHz 300 Bd Not authorized 
28-50 MHz 1200 Bd Not authorized 
50-220 MHz 19,600 Bd* 20—kHz bandwidth 
220-902 MHz 56,000 Bd 100-kHz2 bandwidth 
>902 MHz 56,000 Bd Any bandwidth 


within given 
amateur band 


*19,200 is the standard rate. 


The above modulation-rate and band-=- 
width limitations have served us well up 
to now and perhaps sometime in the future. 
But one can anticipate the need to press 
the limits upward over time. In acountry 
starting with a "clean slate," it may be 
possible to incorporate more liberal pro- 
visions from the outset. 


The 300-baud limitation at HF may be 
overrestrictive in that higher rates are 
possible. There are experimental modems 
developed by industry for the military 
that operate at 9600 bauds (serial not 
parallel signaling) in a single-sideband 
speech bandwidth (8 kHz). They use so- 
phisticated "learning" techniques, require 
computer processing, and are beyond Ama- 
teur Radio pocketbooks for now but not 
necessarily forever. A speed of 1200 
bauds would appear to be a reasonable 
upper limit for amateurs. Through the use 
of m-ary modulation techniques, actual 
data rates of 2400 or 4800 could be ac- 
complished with learning and computer 
processing. If specified in bandwidth, 
with a spectrally conservative modulation 
technique and proper filtering a 1200-baud 
Signal could be kept well within a 1500-Hz 


bandwidth. 


On freguencies between 220 and 902 
MHz, the modulation rate permitted by the 
FCC (56,000 bauds) is a standard rate for 
North America but not for the rest of the 
world, which follows CCITT guidelines for 
speeds. The CCITT number being recom- 
mended for the Integrated Service Digital 
Network (ISDN) is 64,000 bit/s. Perhaps 
U.S. amateurs should follow that standard 
rather than North American telephone prac- 
tices. 


Eventually it may be necessary to ask 
the FCC to raise the speedlimitabove 902 
MHz to either "no limit" or something in 
the megabit-per-second range. Here again, 
there are some differences between North 
American and CCITT recommended speeds for 
"first-order" pulse-code modulation (PCM) 
networks, which are 1.544 and 2.048 
Mbit/s, respectively. 


Emissions 


The new emission symbols adopted in 
the World Administrative Radio Conference 
(WARC-79) are more specific than those 
used for so many previous years. Further- 
more, they do not correspond, one for one, 
with the old ones. In addition to des- 
cribing the signal as it appears on the 
air, the new symbols also are specific as 
to how the signal is generated. This 
makes it difficult to translate old sym- 
bols into new ones. 


For packet radio, it is desirable to 
have a very broad description of permissi- 
ble types of modulation in therules. It 
might be possible simply to specify some- 
thing like "data transmission, telemetry 
and telecommand by any amplitude modula- 
tion, angle modulation, or a combination 
thereof, using bandwidths in keeping with 
good engineering practice." Amplitude 
modulation and angle modulation cover 
everything except pulse modulation. For 
reasons probably needing reexamination 
today, pulse modulation is not permitted 
on the lower-frequency bands. Pulse modu- 
lation would be valuable for future 
higher-speed packet-radio applications. 


The other alternative is to specify 
every possible modulation scheme by emis- 
Sion symbol. This becomes cumbersome. 
For example, the old symbol, Fl could be 
translated to FID, but that covers only 
direct frequency shift of the main car- 
rier. F1D does not include phase-shift 
keying (PSK), which would be G1D. To make 
things more complex, either frequency or 
phase shift of a subcarrier modulating a 
Ssingle-sideband transmitter would make the 
emission symbol J2D. Further, it is pos- 
sible to suppress the sideband of a high- 
speed data transmission as commonly done 
for speech: that would be JIA. There 
could be other specific emission designa- 
tors if two or more channels are nmulti- 


plexed or if pulse modulation is used, 
both of which could occur at megabit-per- 
second speeds. 


It appears that the better approach 
to emissions, particularly for packet 
radio, is to ask the administration to 
give amateurs only broad guidelines that 
will not stifle experimentation. That 
would also ensure that international 
packet-radio communications will not be 
hampered by incompatibility caused by 
overspecificity. 


Station Identification 


At one time, digital transmissions 
had to be identified by Morse code under 
FCC rules. It was liberalized to permit 
identification in any of the specified 
digital codes (ITA2, AMTGR and ASCII). 
Using the AX.25 link-layer protocol, the 
call signs of the addressed station and 
sending station are sent at the beginning 
of each packet transmission, in ASCII. 
This meets FCC identification requirements 
and lets any monitors know who is trans- 
mitting and who is intended to receive the 
packet. Where digipeaters are used, the 
AX.25 address field is extended to include 
the call signs of each digipeater along 
the way. 


It appears that the AX.25 addressing 
arrangement meets at least the spirit of 
identification requirements anywhere. 
However, the regulations of some adminis- 
trations may require amendment or at least 
reinterpretation. For example, a national 
licensing authority may require that the 
call signs of the addressed and sending 
stations be transmitted at the beginning 
and the end of each transmission. It may 
be possible to successfully argue that the 
beginning and end of a packet lasting only 
one second are so close together that only 
one identification is needed per packet. 


Conformity to Widely Recognized Standards 


When AMTOR was new, FCC acceptance of 
this mode was easy, in part, because of 
the existence of CCIR Recommendation 476-2 
specifying this mode for international 
maritime use. The FCC authorized AMTOR by 
Simply incorporating by reference Rec. 
476-2, and later 476-3, in the rules. It 
may be generalized that following industry 
and international standards strengthens a 
case in petitioning regulatory authorities 
for rules changes in the Amateur Service. 


If rules changes are needed to permit 
packet radio, it can be stated that 
packet-switching techniques are now in 
widespread use throughout the world in 
other communications services. The AX.25 
link-layer protocol follows a number of 
international standards, principally: 


Q International Organization for 
Standardization (ISO) standard ISO 3309, 


Data communication-—-High-level data link 
control link procedures--Frame structure. 


o International Telegraph and 
Telephone Consultative Committee (CCITT) 
Recommendation X.25, Interface between 
data terminal equipment and data circuit- 
terminating equipment for terminals opera- 
ting in the packet mode on public data 
networks. 


In development of packet-radio stan- 
dards and practices, the ARRL approach has 
been to follow international (as dis- 
tinguished from national) standards to the 
degree feasible. Amateurs in the U.S. are 
using modems that conform to North Ameri- 
can Bell Telephone standards (not CCITT) 
for packet radio. This practice was 
brought about by the ready availability of 
Bell Telephone modems at surplus prices. 
Fortunately, Bell and CCITT modem incompa- 
tibilities are somewhat moot when used via 
Amateur Radio. On HF, for example, Bell 
103 and CCITT V.21 can communicate through 
SSB transceivers because the frequency 
shift. in both: cases. is.-200 Hz; the ditfer— 
ence in tones is easily compensated for by 
tuning of the transceiver. On VHF and 
UHF, there is little radio contact between 
North America and other continents except 
via satellite. The ARRL has not taken a 
position on packet-radio modems standards 
to date. However, any future recommenda- 
tions will be developed with due conside- 
ration to international standards. The 
existence of integrated circuits capable 
of multiple Bell and CCITT modem protocols 
helps to diffuse modem standards as a 
serious issue. A modem using the AM7910 


chip is shown in the current ARRL Hand- 
book 


Third Party Trattie, 


Perhaps the most sensitive issue is 
third-party Brattice. Packet radio is 
technically suited to handle third-party 
traffic where permitted and may, in time, 
supplant manual transmission methods. 
Rules governing third-party traffic are 
quite liberal in the United States and 
certain other countries. There are cer- 
tain restrictions to prohibit competition 
with common carriers and other commercial 
radio services. Yet, we are aware that 
other philosophies govern third-party 
traffic rules in other countries; many 
outlaw it entirely, while others have 
exceptions only for declared emergencies. 
In some cases, the regulatory language 
prohibiting third-party traffic was so 
broad as to rule out repeaters. 


As the packet-radio network grows, 
there will be a "technical imperative" to 
have message traffic relayed from one 
country to another possibly through inter- 
mediary countries. If the third-party- 
traffic rules are nonuniform, routing 
requirements could become chaotic for 
international messages. Or, unfortunate- 


ly, amateurs may simply choose to ignore 
provisions in the rules that seem incon- 
venient. Thus, the technical imperative 
takes over: It is possible; therefore do 
itl 


It maybe appropriate for the IARU to 
take the lead in developing "model regula- 
tions" pertaining to third-party traffic. 
If there is broad international agreement 
on a workable model based on a set of 
there is a good chance of favorable con- 
sideration by licensing authorities. 


CONCLUSIONS 


Packet radio is here now and is 
growing at a substantial rate. There is a 
sufficient technical base for its 
development throughout Region 3. National 
Societies can encourage its orderly growth 
by providing accurate and timely informa- 
tion, and by supporting their centers of 
excellence, as detailed above. Liaison 
with regulatory authorities is also a 
special role of National Societies; goals 
should be to a) assure that officials have 
a proper appreciation of this new techno- 
logy and b) convince the authorities of 
the need to modernize regulations to ac- 
commodate new modes such as packet radio. 
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WELCOME. 


Welcome to Gateway, the ARRL packet-radio 
newsletter. Some of you reading this are deeply 
involved in amateur packet radio, some of you are 
just getting started on this exciting new mode, 
and some of you aren’t quite sure what “packet 
radio” is. We hope that Gateway will have 
something to offer each of you. 


WHAT IS A “GATEWAY?” 


A gateway is a station that link6 two 
communication6 networks. In amateur packet radio, 
gateway stations are being used communicate 
between VHF and HF networks, and between VHF 
network6 and satellite channels. Eventually, 
users of local VHF networks will use gateways to 
connect to an internat ional packet-radio network. 
We have called this newsletter Gateway because we 
hope that it will, like a gateway station, 
facilitate communications between amateurs 
interested in packet radio. 


Gateway will not be a technical newsletter; 
there are already several ‘fine packet-radio 
newsletters covering technical issues. This will 
be a “news” newsletter. At ARRL Headquarters we 
have many sources of news not all of which are 
available to each of you. This newaletter will 
bring together notes from these sources. 
Overseas and domestic packet-radio club 
newsletters, the FCC, the IARU, on-line 
conferences and on-the-air bulletin boards will 
contribute. You may see items that you’ve seen 
elsewhere, but you should also see things that are 
new and interesting. 


Some of you are receiving this packet-radio 
newsletter and have never even considered what 
packet radio can do for you, or what fun you could 
have on packet. We hope to provide you with an 
overview of the state of amateur packet radio, 
explaining what is being done and what can be done 
on this new mode. 


It seems as though every packet-radio club is 
undertaking some project that will advance amateur 
packet radio. To make these projects fruitful, we 
must make the most of the limited resources 
available to amateurs. By telling a large 
audience about various packet-radio development 
efforts, Gateway should help organizers direct 
their efforts, and help volunteers find the groups 
that need them. 


Perhaps when there is a worldwide amateur 
packet-radio network there will be no need for 
packet-radio newsletters. Until then, we hope 
that Gateway informs and interests you. 


Premier 
Issue 


PACKET METEOR SCATTER 


Last weekend’s Persieds meteor shower provided 
a good opportunity to experiment with packet-radio 
meteor-scatter operation. Rich Zwirko, KIHTV, set 
forth some experimental guidelines, and stations 
throughout the U.S. attempted MS QSOs. 


On August 1, well before the peak of the 
Persiecis, W@RPK, the station of the Central Iowa 
Technical Society, held schedules with Bob 
Carpenter, W30TC, in Maryland. The skeds were on 
6 meters. Bob received about 2% of the packet6 
sent from Iowa. Four nights later, again on 6 
meters, W30TC and W@RPK had what is believed to be 
the first amateur packet-radio meteor-scatter QS0. 


As the Persieds approached, stations tried 
their luck on the Z-meter band. Stations in the 
East included KI1HTV; Vern Riportella, WA2LQQ; Tom 
Clark, W3IWI; Hank Oredson, W@RLI; and Mark 
Wilson, AA2Z. In the West were Ralph Wallio, 
WORPK; Bob McCaffrey, K#CY; Ron Dunbar, WO#PN; Mike 
McQuiston, WA®WYW; Bob Schiers, N#AN; and Terry 
Van Benschoten, WGVB. Several of these stations 
copied beacons and connect requests via MS. On 
the morning of August 12, during the peak of the 
shower, W@RPK and KIHTV completed the first packet 
MS QSO on 2 meters. Congratulations are in order 
for all stations involved in these tests, and I 
hope that I haven’t left anyone out. 


These tests were performed at 1200 bauds, 
using AFSK FM. While it was necessary to use this 
mode in order to include as many stations a6 
possible in the experiments, a performance 
sacrifice was made. We should organize further 
tests at higher transmission rates with more 
efficient modulation techniques. 


ARRL APPOINTED TARU PACKET CENTER 


The ARRL has been appointed IARU packet radio 
“information clearing house.” The following is 
exerpted from the minutes of the IARU meeting in 
late July: "ARRL is nominated as the international 
clearing house of information relating to packet 
radio on behalf of the IARU, with a view to 
encouraging common standards and regulations.” 


This points the way toward international 
understanding and acceptance of packet radio 
standards generated in the United States aad 
Canada. Several European amateurs have hesitated 
to get involved in packet radio because they were 
not sure which standards would “catch on." The 
appointment should help to alleviate this 
confusion abroad as to what is really happening in 
North American packet radio. 


PACKET RADTO ON NETWORK TV 


On July 16 at 0745 PDT, a packet from N6ECT 
was heard throughout the nation on the CBS Morning 
News show. Curtis Spangler, N6ECT, was being 
interviewed by CBS. for a_ piece on the 
Haight/Ashbury and the film crew focused on his 
CRT. AS luck would have it, Curtis was 
transmitting packet6 through the KA6M digipeater. 
The audio from one of the packet6 came through 
loud and clear, and the frame was heard in all 50 
states and throughout half the world! Via KA6M. 


220 MHz and PACKET RADIO 


The 220-MHz band is crucial to packet radio 
for a couple of reasons. Because it is the lowest 
frequency band on which we can exceed 19,600 
bauds, it 1s going to be used for the initial 
high-speed intercity linking. It is not being 
used for any satellite uplinks or downlinks, and 
60 it is essential for full-duplex teleport 
stations. With these considerations in mind, we 
note the following: 


The Tri-State Amateur Repeater Council has 
coordinated a 100-kHz channel from 220.5 MHz to 
220.6 MHz for wideband digital communications. 
This council coordinate6 VHF frequencies in 
northern New Jersey, southwestern New York 
(including Long Island) and Connecticut. This 
paves the way for EASTNET linking to begin as soon 
as hardware and software are ready. 


On the negative side are two petitions for 
rule making which threaten the 220-MHz amateur 
band. The first 1s RM-4829 from the Land Mobile 
Communication6 Council. This petition calls for 
the FCC “to explore the potential use of vacant 
spectrum in the UHF TV bands, spectrum allocated 
for ‘Fedral Government use, or assignments from the 
band 220-225 MHz to satisfy the requirements of 
land mobile users.” This may sound worse than it 
is, since the petition goes on to say “Because of 
the limited number of channel6 that the 220-225 
MHz band will provide, however, it is not 
anticipated that this spectrum can meet the 
immediate requirements of land mobile licensees.” 


Another petitioa (RM 4831),from a 
manufacturer of amplituce compandored sideband 
equipment) explicitly requests reallocation of the 
band 216-225 MHz. This petition poses a_ serious 
threat to the 220-MHz amateur band. 


Packet radio needs the 220-MHz band. Be sure 
to read these petitions and send your comments to 
the FCC. The comment procedure was outlined in 
OST, March, 1982. The comment deadline for these 
two petitions is August 29, 1984. 


WHAT’S BREWING AT TAPR? 


This piece came from Harold Price’s answer to 
the question "Is TAPR up to something?” Harold is 
part of the TAPR software design team, and he made 
these comments while he was “Member of the Month” 
on Compuserve’s HAMNET. 


“The following views are mine alone, and do 
not necessarily refect those of TAPR, AMSAT, VITA, 
LAPG the staff, management, or janitorial 
departments. 


“The TAPR folk6 are indeed up to something. 
We have the TAPR Pascal code running happily under 
a simulated environment again. The software, with 
only one change, runs under TURBO Pascal on the 
Pronto-16. This will vastly speed up development, 
which has slowed down as of late. 


“The plan is to come up with version 4.0 of 
the TAPR TNC software which will allow testing of 
both datagram and virtual connection protocols. I 
think the level two wars are over. With. 1300 TNCs 
in the field from 6 "“manufactuers" all running the 
same level two, anyone proposing a switch now is 
just rocking the boat. The few proposals I’ve 
seen for different level twos offer no concrete 
advantage6 over what we’ve got now anyway. 
Besides, level two is boring (now that we have one 
that works). The real fun is level three. 


“For the newcomer, level two refer6 to a 
point to point protocol, linking one TNC to 
another with no TNCs in the middle. There is 
currently a necessary kludge in AX.25 called 
digipeating which is a very demented level three 
feature. Digipeating allows two TNCs to be 
connected using a third as a relay. Without this 
simple addition to AX.25, packet may not have 
taken off as it did, since digipeating allows many 
more users to reach each other. If you haven’t 
got a wide-coverage duplex repeater (or even if 
you have), digipeating is your best bet for now, 


“Anyway, level two is point to point, with 
level two+ in current style, multihop dumb 
repeating. The + in level two will die a happy 
death when we get level three up and running. 
Level three link6 two end points thru multiple 
intermediate INCs. The linking is done in an 
intelligent manner. ACKing is node to node rather 
than end to end. In level two digipeating, each 
intermediate point simply regenerates the packet. 
It does not ACK it. The final end point ACKs it, 
and the ACK is blindly repeated back to the 
starting point. If any repeat of the packet, or 
the ACK, is’ stepped on or dropped, the packet must 
start over from the beginning. 


“In level three, an ACK can occur at each 
step of the way. Thus, a packet may only have to 
be re-sent between relay points five and six, 
rather than starting again at point one. So why 
don’t we get on with it, you might ask? 


“There are many problems involved in design 
and implementation of a level three network -- 
flow control, network blocking, routing, on and 
on. What is TAPR doing? 


1) A node in a level three network will want 
to be connected to more than one other node. We 
will allow the TAPR TNC to maintain multiple level 
two connects. This has several implications. 
First, you can carry on two or more concurrent 
conversat ions. Not so good for rag chewing maybe, 
but great for emergency communications. Imagine a 
TNC in the local disaster center. Currently you 
can carry on a conversation with only one other 
TNC, with limited possibility of a priority break- 
in from another TNC. With all outlying TNCs 
connected to the central node at the same time you 
get closer to what you want, high reliability 
connections with each of the field guys at the 
same time. 


An 


Introduction 


to Packet Radio 


Jon Bloom, KE3Z 
ARRLLaboratory Engineer 


Perhaps you have heard or read of packet 
radio but are unsure just what this new mode is. 
Does the idea of error-free communication at high 
speed interest you? How would you like to use a 
remote computer to get propagation charts, 
satellite tracking data or leave messages for your 
friends? Or maybe just play a computer game? All 
of this, and more, is possible via packet radio. 


No More "Hits"! 


Packet radio is a digital communications 
mode. Don’t be scared off by this impressive 
sounding phrase; old-fashioned RTTY is a digital 
mode too. So is CW in the most literal sense! A 
digital mode is simply one which is transmitted by 
sending a signal with only two states: on and off 
for CW, mark frequency and space frequency for 
RTTY. In fact, packet radio serves much the same 
purpose as RTTY but packet has a number of 
improvements that make it more versatile and 
useful. One of the major failings of RTTY is its 
susceptibility to errors. In other words, as 
signals fade or QRM appears the “print” suffers 
errors. When this occurs in a RTTY QSO it is 
impossible to determine what was actually supposed 
to be printed. This is probably the major area in 
which packet radio improves upon RTTY. When an 
error occurs in the received packet signal, it is 
detected, and the information is automatically 
retransmitted. In fact, retransmission of the 
information will keep occurring until the 
receiving station transmits an acknowledgement, or 
ACK, to the transmitter. Since the error- 
detection technique is very sophisticated, there 
is almost no chance of accepting erroneous 
informat ion. This automatic repeat request is 
known as ARQ. 


To make the ARQ system work, the transmitter 
must pause from time to time to allow the receiver 
to send its ACK. In packet radio, the transmitter 
will send a burst of information (a packet) to 
which the receiver will reply with an ACK signal 
if the packet was received without errors. If the 
transmitter does not get an ACK back, it waits a 
short time and then retransmits the packet. 
Unlike other digital modes such as RTTY and AMTOR, 
the packet station waits until it has a number of 
characters to send before transmitting. For 
“chat” type operation, the packet station will 


generally transmit the information after a 
complete line has been typed or after a specified 
number of characters has been entered. The 
station then activates the transmitter, sends the 
informat ion, goes back to receive mode and waits 
for the ACK. If the ACK is received right away, 
the transmitter will remain off until the next 
line is ready to be sent. So for much of the time 
neither of the stations are transmitting at all! 
It is this characteristic of packet radio which 
allows another benefit of the mode: channel 
sharing. It is not at all uncommon for two or 
three (or more> QS80s to be taking place on the 
same frequency at the same time! Of course, 
occasionally two stations will transmit at the 
same time and clobber one another, but because of 
the ARQ function they will each try again, and the 
information will get through. Since the VHF 
packet signals are sent at 1200 bauds (more than 
20 times as fast as normal Baudot RTTY) it doesn’t 
take too long to get the information through, 
either. 


Protocols = The Bedrock of Digital Communications 


To make packet radio work, all of the 
stations need to be using the same protocol. 
Again, don’t let this term make you nervous. Hams 
have been using protocols for many years. A 
protocol is simply a defined way of doing things. 
The standard amateur message format is one example 
of a protocol. It exists so that all traffic 
handlers will know exactly what information is 
required to refer to a given message and so that 
the receiving operator will know what to expect 
next as the message is being received. Another 
protocol is the RTTY character frame. It has a 
particular make-up consisting of a start bit of 
specified frequency and length, five information 
bits in the proper sequence and a stop bit. 
Imagine the confusion if each station sent a 
different length start bit or sent the information 
bits in any convenient order! In packet radio, 
there are actually several protocols in use. Each 
of these protocols supports the operation of the 
protocol above it. We say “above” because of the 
way we look at how the packet protocols support 
one another. The model we use  is_ the 
International Organization for Standardization 
(OSI) network reference model. This model shows 
seven layers of protocol. 


In packet radio, the first protocol layer 
defines the way in which the information from the 
higher layers is sent as a sequence of mark and 
space frequencies (or amplitudes or phases) by the 
transmitter. On VHF, packet radio stations 
currently use Bell 202 modems to transmit and 
receive AFSK signals. Standards for HF use are 
still being developed. 


The layer 2 protocol specifies how the 
information is converted to a sequence of bits and 
what information is sent by the two stations to 
insure that the packets wili be printed in proper 
sequence and without errors. Layer 2 consists of 
two protocols. The first of these is an 
international standard known as High Level Data 
Link Control (HDLC). (Confused? Don’t worry. 
You don’t have to understand all of this 
background information to operate packet. It’s 
just nice to have some idea what the packet 
experimenter types are talking about!) The second 
layer 2 protocol in use by amateurs is called 
AX.25 and is a variation of the commercially used 
X.25 standard layer 2 protocol. The major change 
which was made by the amateurs is the inclusion of 
call signs in each and every frame of the 
transmissions. As we mentioned before, more than 
one QSO can occur on a given frequency at the same 
time. How is a receiving station to know which of 
the transmissions are part of his own QSO? This 
is accomplished by addressing, each frame with the 
call sign of the receiving station. The call sign 
of the transmitting station is included as well. 
Aside from the need of this addressing to make the 
protocol work, it makes it possible for stations 
monitoring the frequency to see who is 
transmitting. It also constitutes a legal station 
ID for FCC purposes, This eliminates the need for 
the operator to explicity identify his station. 


Packet Radio Today 


Most of the packet-radio activity today is 
carried out using standard 2-meter FM radios. 
Along with the FM rig, the packet station consists 
of computer or video terminal and a terminal node 
controller (TNC), The TNC is a small 
microcomputer which executes the packet~radio 
protocols. It sends the information for display 
to the terminal or computer and gets the 
information to send from the same device. Several 
manufacturers now produce TNC kits and assembled 


units. 


A repeater is commonly used to extend the 
range of VHF FM stations. Although a standard 
voice repeater may be used to repeat packet 
signals, there is a simpler way. The _digipeater 
is a packet-only repeater. Along with the call 
sign of the transmitting and receiving stations, a 
packet frame may contain one or more digipeater 
call signs. When a digipeater receives an error- 
free packet frame it checks for the presence of 
its own call sign. If the call sign is found, the 
digipeater retransmits the frame. Since the 
digipeater does not operate in full-duplex mode, 
it requires only a single frequency. Also, it 
does not need any duplexer or sophisticated 
control circuitry as does a voice repeater. A 
digipeater need only consist of a standard 2-meter 
rig, a TNC and a good VHF location! With more 
than one digipeater address in the frame, the 
packet may be made to hop from one repeater to the 
next. Large distances may be traversed in this 
way. 


The Future of Packet Radio 


A packet network is formed when a number of 
stations can communicate with one another through 
a common set of communication links. A 
rudimentary network is formed when a number of 
stations are connected directly or through 
digipeaters. A more effective network would have 
the ability to intelligently repeat the frames 
along a route between the sending station and the 
destination station regardless of the distance 
between the endpoints. It is this facility that 
is the next major effort to be undertaken in 
packet radio. To accomplish this, a level 3 
(network) protocol must be specified and 
implemented. The expectation is that level 3 
should become a reality in 1985. As more packet 
stations come on the air, QS0s between far distant 
stations will be possible. Imagine using a 2~ 
meter hand-held radio to communicate with stations 
across the country! Soon it will be possible. 


Chewing the rag is close to the ham’s heart, 
but that type of operation only scratches the 
surface of the potential of packet radio. 
Computerized server stations are providing 
bulletin-board and remotely operated computer 
services now. More esoteric servers will be built 
in the coming years. Such new possibilities as 
digitized voice and video have barely been 
explored to date, leaving plenty to do for both 
experimenters and users. The OSCAR satellites are 
being used for packet radio now. With the packet- 
radio satellite (PACSAT) scheduled for launch in 
1986, space communications promises to play a big 
part in packet. The high frequencies have not 
been neglected either. Experimental packet 
transmissions on 10 and 28 MHz have proven the 
viability of packet as an HF mode. Improved 
techniques for HF use are being developed now. 
Expect to see packet on HF in a big way within a 
short time. 


Amateur Radio is not being left behind in 
this age of the home computer revolution. Packet 
radio allows the amateur to combine his or her 
interest in the radio art with the high-tech world 
of computers. With the communication potential of 
amateur radio added to the information processing 
of the computer, the coming years should show a 
dramatic increase in the capability of the typical 
ham stat ion. Get in on the ground floor now! 
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“Next, and even better, you can automatically 
route one connection stream to another. Maybe an 
example is called for. The syntax below is 
probably not what we’ll end up with, but the idea 
is: 

MYCALL NK6K 
{1 ] CONNECT WB6YMH 

[1] CONNECTED TO WB6YMH 
[2] CONNECT WA6JPR 

[2] CONNECTED TO WA6JPR 
ROUTE [1] TO [2] 


“Your TNC is now a network node. Anything 
that comes in from stream [1] gets ACKed at level 
two. The data from the packet gets routed to 
stream [2] where it gets sent out and saved until 
an ACK cones in on stream [2]. The reverse is 
also true, incoming from [2] goes to [1]. 


“Now, wouldn’t it be great if you could cause 
the other guys board to make a connection? If I 
could tell WA6JPR to make a level two connection 
to WBSEKU? Then what we have is the level three 
function, endpoints linked thru multiple 
intermediate points. A lot of things are missing, 
but this simple mechanism allows testing of level 
three concepts without a lot of hassle on the 
users part. Wewil’ also design an interface 
(based on asyncronous LABP) between the TNC and 
its attached computer to allow the computer full 
control over the link process. This permits the 
use of the TAPR TNC as a level two black box, with 
level three functions done in your host. 


“Do I expect everyone to run verson 4? Well, 
why not? Version 3.1 can still be used point to 
point, and thru 4.0 gateways get full access to 
network. But just as everyone having the 
capability of being a digipeater added to the 
swift growth of packet, so will the ability of 
each TNC to be a level three node. 


“But I ramble. Not only does a network node 
need to support multiple level two connections, it 
might also need to support connections on multiple 
RF channels. Let’s assume a 1200-baud link on 2 
meters and a 2400-baud link on 220, feeding a 9600 
baud I ‘nk on 440. The hardware arm of TAPR is 
designing a fancy multiport hardware controller. 
Several designs have been proposed, including a 
motherboard with slots for plugging in a number of 
channel-controller cards. Each channel-controller 
card is a mini TNC, handling all channel-access 
and level two functions. The mother board passes 
data between channels and handles level three and 
higher functions. 


“We don’t expect everyone to have one of 
these TNC-LINKS (say “tink link”). But they will 
make great mountain-top controllers, especially 
when used with the PACSAT 9600 whiz-bang modem, 
which has been described elsewhere. 


“How long do I see TAPR building kits? There 
are two answers: “As long as there is a demand” or 
“Until we can’t stand the sight of them anymore.” 
I haven’t been pressed into the chain gang of kit 
packaging, but isn’t much fun, especially when 
serial number 1000 has long since gone out the 
door. The kits are TAPR’s only source of income. 
An extremely small amount of each $240.00 goes 
into our fund for future development. I have 
forgotten how much. A number that does come to 
mind is the cost of the cabinet kit. Your cost, 
$69.00, our cost, $67.00. Our original goal was 


to make packet available to a large number of 
people at reasonable cost, delivering as full a 
function device as we could. It is possible to 
deliver less function for less cost. It is 
possible to deliver the same function assembled, 
tested, and warranted, for a larger cost. There 
are several market niches out there, and we will 
continue to ship as long as 1) there is a niche 
for us and 2) we’re having a good time. 


“Are we having fun yet? You bet! 


“One final note. A for-profit company would 
be crazy to discuss future products like this 
before the product is ready to ship. But we’re a 
nonprofit R&D company, trying to make packet the 
mode of the future. And remember, you saw it here 
first.” Via HAHNET. 


Club Listing 


Here is a list of clubs active in Amateur packet 
radio . 


Amateur Radio Research and Development Corp. 
(AMRAD ) 

P.O. Drawer 6148 

McLean, VA 2210606148 


Amateur Radio Satellite Corp. (AMSAT) 
P.O, Box 27 
Washington, DC 20044 


Chicago Area Packet Radio Association (CAPRA) 
P.O. Box 8251 
Rolling Meadows, IL 60008 


Central Iowa Technical Society (CITS) 
c/o Ralph Wallio, W@RPK 

Rural Route 4 

Ind ianola, IA 50125 


Florida Amateur Digital Communications Assn. 
(FADCA) 

c/o Ted Huff, K4NTA 

1829 N. W. Pinetree Way 

Stuart, FL 33494 


Los Angeles Area Packet Group (LAPG) 
c/o Harold Price, NK6K 

1211 Ford Ave. 

Redondo Beach, CA 90278 


Minnesota Amateur Packet Radio (MAPR) 
c/o Philip S. Plumbo, N@DFT 

1128 Dayton Avenue 

St. Paul, MN 55104 


New England Packet Radio Assn. (NEPRA) 
P.O. Box 15 
Bedford, MA 01730 


Rocky Mountain Packet Amateur Radio Assn. (RMPAR) 
c/o Andy Freeborn, N#CCZ 

52222 Borrego Drive 

Colorado Springs, CO 80918 


San Diego Packet Group (SDPG) 
c/o Mike Brock, WB6HHV 

10230 Mayor Circle 

San Deigo, CA 92126 


Tucson Amateur Packet Radio Corp. (TAPR) 
F.O. Box 22888 
Tucson, AZ 85734 


Vancouver Amateur Digital Communications Group 
(VADCG) 

9531 Odin Road 

Richmond, BC V6X l1El 

CANADA 


Remember to include an 8.a.s.e when writing to any 
of these clubs. Club money spent on postage is 
money that can’t go into packet-radio development. 


We also know of the following individual who would 
like to form a packet-radio club: 


Doug Baker, K4CLE 
8724 Cumbernauld Circle 
Germantown, TN 38138 


Voice Nets Concerning Packet Radio 


The following voice nets are devoted to discussion 
of packet radio. 


Day Time Frequency Coverage Sponsor. 
Mon 2000 PDT 145.36 Los Angeles LAPG 
Tue 2100 PDT 144.76 San Diego SDPG 
Tue 2200 EDT 3.850 Eastern U.S. ‘AMSAT 
Thu 2000 EDT 147.12172 Boston area NEPRA 
Sun 1900 UTC 14.235 Nat ional TAPR 
Sun 2100 UTC 7,158 Nat ional TAPR 
Sun 0800 EDT 3.958 Regional FADCA 
Sun 1900 EDT 147.165 Tampa area FADCA 


Orlando area FADCA 
Central U.S. CITS 


Sun 2100 EDT 147.285 
Sun 1500 CDT 7.158 
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GATEWAY SUBSCRIPTIONS 


If you have received the first two issues of 
Gateway for free, now is the time to subscribe. 
We have to recover the cost of producing, 
printing, and mailing the newsletter. 
Subscription information can be found on the back 


page. 
GATEWAY INPUT 


Is there packet activity in your area which you 
think would be of interest to the readers of 
Gateway’? If there is, send it along to ARRL Hg, 
marked “Attent ion: Gateway Editor.” This 
newsletter was started to distribute information 
about packet radio throughout the world. Send us 
a summary of activity on your packet network or 
tell us of any packet-radio related R+D work going 
on in your area. 


HF PACKET BULLETIN BOARD 


You can now connect to the W@RLI packet bulletin- 
board system (PBBS) on tventy meters. The PBBS is 
located near Boston, MA, and is run by Hank 
Oredson, W@RLI. Hank has had the PBBS on 145.@1 
MHz for several months, and it has become one of 
the ma jot “servers” for the large Boston-area 
packet network. 


The W@RLI PBBS software, written by Hank in z8¢g 
assembly language, runs on a Xerox 82§ with a TAPR 
THC. The PBBS provides automatic time/date stamps 
for messages, automatically delete6 inactive 
messages, and will even try to send you a beacon 
if there is mail waiting for you. Now, with the 
addition of a second TAPR TNC, the bulletin board 
is available on both HF and VHF. 


On twenty meters you will find the PBBS as near 
14.080 MHz as band occupation permits. Use 399 
bauds, and 299-Hz shift. (The same shift and 
speed used by 1§-MHz packet stations.) When you 
connect to W#RLI, the PBBS will send you operating 
instructions. Via W9RLI. 


NTS TRAFFIC VIA PACKET 


WORLI’s PBBS is also being used to originate NTS 
traffic. Messages are stored in standard NTS 
format, with the preamble information on the first 
line of the message. The PBBS is checked each 
evening and messages are then delivered to the 
appropriate NTS net. 


Packet radio is a valuable tool for traffic 
handling: “CE Course, the: setisnal-seckst meceere 
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that we are working toward will be a perfect 
traffic-handling tool, but what we already have 
can and should be connected to RTS. The existing 
local networks can be used for message origination 
and delivery. Two packet stations on 19 MHz or 
OSCAR-1$9 could provide TCC service. These 
operations could begin today if NTS officials 
contacted packeteers, or packeteers contacted NTS 
officials. Let’s get started! 
Via The NEPRA Packetear. 


PACKET RADIO AND ARES 


Among packeteers, it iS “common knowledge” that 
packet radio would be a good mode for the high- 
volume, error-free communications needed during 
emergencies. Unfortunately, this knowledge has 
yet to reach the leader6 and operators in the 
Amateur Radio Emergency Service (ARES). To remedy 
this, a new chapter has been added to the ARRL’s 
Emergency Coordinator’s Handbook. 


In July, Mike Riley, WF4R, editor of the EC 
Handbook, met with Terry Fox, WB4JFI, of AMRAD. 
The two discussed ways in which packet radio could 
aid the ARES. The new ten-page “Packet Radio" 
chapter in the EC_Handbook is the result of that 
discussion. 


The EC Handbook is sent free-of-charge to all 
Emergency Coordinators. The latest edition, vith 
the packet-radio chapter, will be available early 
in September. At that time, packet-radio 
enthusiasts should be prepared to discus6 
emergency operations with their ECs. 


HIGH-SPEED PACKETS 


On August 23, Curtis Spangler, N6ECT, and Mike 
Flynn, W2FRT, exchanged packets at 9699 bauds 
using quadrature amplitude modulation (QAM) 
techniques. Both stations were using personal 
computers, 96f%-bit/s modems, homemade radio/modem 
interfaces, and 44$-MHz radios. Special software, 
vritten in Turbo Pascal, drove the synchronous 
data link controller (SDLC) cards inthe 
computers. Over the five-mile path betveen the 
stations, there were no errors using 1§ watts, and 
69% to 7¢% throughput at one watt. Via KA6M 


TELEPORT STA 


On August 6, the ARRL and AMSAT filed a request 
for special temporary authority for the operation 
of teleport stations. The following comes from 
the text of the STA: 


“The operations of the stations operating under 
the STA will involve communications vith 
terrestrial Amateur Radio Stations and Amateur 
Radio stations in space operation. They will 
function primarily as intermediary stations 
betveea terrestrial and space Amateur Radio 
stations. We hereby designate these intermediary 
stations ‘teleports.’ 


“The purpose of a teleport is to relay digital 
messages automatically between terrestrial Amateur 
Radio stations and amateur stations in space 
operation (amateur satellites). This need to do 
so is twofold: 


"(1) to obviate the need for every Amateur Radio 
station having a digital communications capability 
to also have an earth station capability in order 
to communicate vith amateur satellites. 


"(2) to provide a measure of traffic-flow control 
for the digital channel(a) on the satellite(s)... 


“There are three primary objectives of this 
request for STA: 


"(1) to determine experimentally what equipment 
and techniques are required to provide near-real- 
time relays between two or more terrestrial 
rtatioas using local teleports and an amateur 
satellite. 


™(2) to determine experimentally what is required 
to provide reliable store-and-forward 
communications wherein the teleport station buffer 
stores the messages between the hours that the 
satellite and terrestrial links are not available 
at the same time. 


"™(3) to gather the necessary information for 
permanent rule change to permit teleport 
operation ." 


The request for STA then goes on to list the 
frequencies of operation, and other administrative 
details. The folloving stations will be 
authorized to operate teleports when the STA is 
approved: John Biro, KIKSY; Tom Clark, W3IWI; Den 
Connors, KD2S; Bob Diersing, N5AHD; John DuBois, 
W1LHDX; David Engle, KE6ZE; Gary Garr iot t, WASFMQ; 
Sumner Hansen, WB6YMH; Lyle Johnson, WA7GXD; Phil 
Karn, KA9Q; Bob McCaffrey, KGCY; Harold Price, 
NK6K; Bill Reed, WDSETZ; Hank Magnuski, KA6M; Vem 
Riportella. WA2LQQ; J ose Sancho-Dominguez, WBSYFU; 
Bob Stric’ .in, NSBRG; ARRL club station, WIAW; and 
AMRAD clu. station, WD4IWG. Building a teleport 
is a demanding task, and no one will have a 
tefeport immediately. Please do not bother these 
operators by asking when their. teleport will be on 
the air. 


OSCAR-16 and UoSAT-OSCAR-11 are the satellites 
that are likely to be used by the authorized 
stations. OSCAR-I& vith its long access times 
and great coverage, will be used to test the near- 
real-time links. UoSAT-OSCAR-11, if it is made 
available at all, will be used for store-and- 
forvard teleports. 


Watch Gateway for further nevs of the STA and the 
stations involved. 


PACKETEERS ARE EVERYWHERE 


meets the eye! This vas brought home to me on a 
recent weekend vhile my vife Linda, KA1ZD, 
daughter Der.yn, and! were vacationing in Nev 
Hampshire. As we were vandering around a computer 
tent sale, someone spotted Linda’s HT and said, “| 
bet you’re a ham.” He turned out to be Dave 
McLanahan, WAIFHB, and ve had a long and pleasant’ 
conversation about all sorts of things. 
Eventually | introduced the subject of packet 
radio, and asked innocently if Dave vas familiar 
with the mode. He was not only familiar with 
packet, he was on it! Living in a bit of an RF 
hole in the vilds of southwestern New Hampshire, 
Dave goes hilltopping vith a ZX81, a S-inch TV 
monitor, and a GLB TNC to connect into the Nashua, 
Nev Hampshire area. With EASTNET growing ag it 
is, he should soon be able to packet without 
leaving his home. Via Dave Sumner, K1ZZ. 


[Dave is General Hanager of the ARRL — Ed.] 


PACKET RADIO IN AUSTRALIA 


There are at least two active packet clubs in 
Australia, one in Melbourne and one in Sydney. 
The newly-formed Melbourne Packet Radio Group 
has four members: J] ohn Smelstorius, VK3ZVR; lan 
Clark, VK3YRR; Peter Jetson, VK3ZMB; and David 
Furst, VK3YDF. These four have started a local 
net using the VADCG protocol. They will be 
attempting to link to the larger group in Sydney. 


The Sydney Amateur Digital Communications Group 
(SADCG) has an active net of about twenty 
stations with a digipeater and a packet bulletin- 
board sys tern. 


Perhaps someone will eet up an HF or satellite 
gateway linking the U.S. and Australia. 
Vis Amateur Radio. 


THE PACKET ADAPTIVE MODEM 


If amateurs are to construct a long-distance 
packet network in the near future, some of the 
cross-country links are going to have to be on HF. 
While HP links are not as reliable as VHF links, 
we simply cannot expect to have a complete chain 
of VHF sites across the country as soon as we need 
it. The HF links will have problems not 
encountered on VHF links, such as long-term fading 
and multipath effects. To combat these problems, 
Bob Watson, and Paul Rinaldo, W4RI, signed the 
Packet Adaptive Modem (PAM). 


Briefly, PAM uses a 6$$-8z shift at 75, 159, 396, 
699, or 1299 bauds. Programmable switched- 
capacitor filters (like those used on the TAPR 
TNC) keep the modem passband as narrow as 
possible, reducing noise and QRH on the received 
signal. In operation, the stations using PAM can 
determine the highest data rate that the link can 
support, and then use that data rate. If the link 
gets vorse, they can go slower. If the link gets 
better, they can adapt and go faster. This should 
allow the use of the best transmission rate for a 
given link. [For further discussion of PAM, see 


Second ARR.L_Amateur Radio Computer Networking 
Conference proceedings, published by the ARRL.] 


PAH is built on an S-19@ card, but only uses the 
$-1¢98 pover supply. Serial I/O an:! filter control 


Jon Bloom, KE3Z, has built two PAMs in the ARRL 
lab. One of these “alpha test” modems will be 
sent to Ralph Waltio, W@RPK, and the cther will be 
set up at WLAW. Testing of the modems will then 
be conducted on several HF bands. 


After these units are tested, the circuit board 
layout will be updated and several “beta test” 
modems will be made available for more videspread 
testing. 


RMPRA PACKET BULLETIN BOARD 


The Rocky Mountain Packet Radio Association 
(RMPRA) is DOV operating what they believe to be 
the most sophisticated packet bulletin board 
around . 


The system is a modified version of The Bread 
Board System (TBBS), by Phil Becker, WBGELV. 
It was donated to RHPRA and modified for packet- 
radio operation by Phil and Dave Ebert, W7RH. 


TBBS is a modular software system that can be 
easily modif ied by the system operator to fit his 
particular needs. The RMPRA version is accessable 
through the Pike’s Peak digipeater or via 
telephone at (3$3)-452-4735. If you want to call 
up and see the softvare in operation, set your 
terminal to 399 bauds, half duplex, 8 data bits 
and no parity. 


23-CM RAND PLANS AND PACKET RADIO 
Although most packet-radio activity is now on the 
tvo-meter band, band plans for the higher VHF and 
UHF bands will have profound effects on the future 
of packet radio. The number of packet stations on 
the air increases daily, and the need for high- 
speed, videband links is becoming obvious in many 
urban areas. Both of these factors will push 
packet radio onto the higher bands, where several 
hundred kiloHertz of band space should be easy to 
come by. 


Since it is important for packet-radio enthusiasts 
to keep track of VHF/UHF spectrum plans, we 
present here a proposed band plan for the 23 cm 
band. 


The ARRL VHF uur Advisory Committee will recommend 
a 23 cm bandplan to the ARRL Board of Directors at 
the B.0.D.’s October meet ing. The latest draft of 
this recommendation contains the following 
allocations of interest to packet-radio operators: 


Wideband communications 
Medium bandwidth 

digital duplex (with 
1288- 1290 ). 
Single-frequency digital 
communicat ions. 

Wideband cocmunicat ions. 
Medium-bandwidth digital 
duplex (with 1258 = 
1268). 

Single-frequency 
communications, eg. 
digital, control links, 
cross-mode and remote 
base. 


1249 MHz ~ 1258 MHz 
1258 MHz ~ 1260 MHz 


1275.5 MHz = 1276 Miz 
1276 MHz - 1288 MHz 


1288 MHz = 1298 MHz 


1297 MHz - 1399 MHz * 


“Wideband communications” includes ATV, spread 
spectrum, and digital. Those portions of the band 
allocated to wideband commuaicatioas will be 
coordinated by region. It is further recommended 
that coordination of multiple users of a single 
channel in local areas can be achieved through 
isolation by means of cross polarization and 
directional beam antennas. 


It should be remembered that the above is a draft 
of a recommendation that will be presented to the 
ARRL Board of Directors. It is not a currently 
adopted bandplan. 


It is important that packet-radio enthusiasts 

in touch with representatives of their local and 

nation81 frequency-coordination groups 60 that 

packet future will be provided for. The 

ARRL Board of Director’6 meeting will be in 

October, so be sure to express your feelings on 
23-cm bandplan to your Director. 


CLUB LISTING CORRECTIONS, ADDITIONS 
Add to the listing of packet-radio clubs: 


Oahu Packet Enthusiasts Club (OPEC) 
P.O. Box 1355 
Pearl City, HI 96782 


Pacific Packet Radio Society (PPRS) 
c/o Hank Magnuski, KA6M 

311 Stanford Avenue 

Menlo Park, CA 94025 


Change these addresses: 


Florida Amateur Digital Communications Association 
(FADCA) 

c/o Gwyn Reedy, WIBEL 

812 Childers Loop 

Brandon, FL 33511 


Rocky Mountain Pakcet Radio Association (RMPRA) 
c/o Andy Freeborn, N#CCZ 

5222 Borrego Drive 

Colorado Springs, CO 8918 


TAPR GETS OFFICE 


Tucson Amateur Packet Radio (TAPR), an 
international Amateur packet radio research and 
development group based in Tucson, Arizona, IS 
proud to announce the opening of its off ice. 


The off ice address is: 


TAPR 

1616 East Pennsylvania Avenue 

Suite 362 

Tucson, AZ 85714 

Phone: (682) 746-1166 

Office hours are 9:99 AH ~ 5:39 PM (MST) Monday 
through Friday. 


The office staff is provided tO expedite 
information requests, provide spare parts support, 
fill orders, etc. They can NOT ansver technical 
quest ions. Technical questions should be routed 
to the TAPR P.O. box (printed in the last issue of 


Gateway). 


AFA PACKET RADIO INFORMATION 


John Gates, N7BII, of Advanced Electronic 
Application6 is willing to talk on the phone or 
correspond by mail to ansver technical questions 
concerning packet radio. 


Contact: AEA 
P.O. Box C2166 
Bldg O&P 26$6~-196th SW 
Lynnvood, WA 98936-8918 


PACKET RADIO AT HAMFESTS 


Several Buffalo, NY, ham radio club6 will be 
sponsoring the HAM=-0O-RAMA at the Erie County 
Fairgrounds on September 7 and 8. This hamfest is 
of intrest to packeteers, since the swap meet will 
feature computer equipment and the presentations 
will address “Computers and Amateur Radio.” J eff 
Ward of ‘the ARRL will give an introduction to 
digital communications at 9:3¢ Saturday morning, 
and Gil Bolke, of GLB Electronics, will discuss 
packet radio later on Saturday. 
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PACKET AT THE BUFFALO HAM-O-RAMA 


I just returned from the Buffalo Ham-0-Rama, a 
large swap meet and convention hosted by several 
radio clubs in Buffalo, NY and neighboring 
Ontario. Packet radio was very well represented, 
both on the technical presentation schedule, and 
in the indoor display area. 


On Saturday morning, I gave a well-attended 
“Introduction to Digital Communications.” I 
finished the talk with a short discussion of 
packet radio, and several people in the audience 
requested more information on packet. Later in 
the afternoon, Gil Boelke, W2EUP, from GLB 
electronics, held an in-depth packet-radio seminar 
and demonstration. It looked like about seventy 
people attended Gil’s talk. 


At the GLB booth, a couple of GLB PKI TNCs vere 
on-the-air. Both of the TNCs were connected to 
computer6 running GLB’s CP/K program. This is a 
CP/M program that makes it easy to control the 
PK1. CP/K provides a menu of commands for the 
PK1, and also facilitates remote operation of CP/M 
computer6 attached to PK1 TNCs. If you have a 
PK1, contact GLB to find out more about the CP/K 
software . 


In the booth next to GLB’s was Bob Richardson, 
W40CH, from Richcraft Engineering. Richcraft 
market6 TNC software that runs on Radio Shack 
computers. (Watch for an upcoming QST article by 
Bob explaining his “software approach” to packet 
radio.) A program demonstrating Richcraft 
software and explaining packet radio was running 
on a TRS-8$ at the Richcraft booth. 


The number of people at the talks on digital 
communication6 and at the two packet-radio booths 
made it clear that more and more amateur radio 
Operator6 are becoming interested in packet radio. 


ST. 1ODIS PACKET RADIO CLUB 


No slight was intended when I left the St. Louis 


Packet Radio Club (SLAPR) off the_Gateway list of 
packet-radio clubs. The omission brought a 
letter from Spencer Branham, KA$IXI, reminding me 
about SLAPR and describing the club’s activities. 
W hat better opportunity to print the first Gateway 
packet-radio club profile? 


SLAPR was formed in the summer of 1982 by Pete 
Eaton, WB9FLW. Pete was one of the mainsprings of 
the Tucson Amateur Packet Radio group during the 
design and implementation of the TAPE TNC. The PC 
board layout for the TAPR Beta-test TNC vas done 
in St. Louis, and the custem power transformers 


for the TNC were manufactured there, SLAPR was 
one of the Beta-test sites for the TAPR TNC, and 
club members have been on-the-air since the first 
TNCs arrived in January, 1983. 


Until 1983, SLAPR_ publiehed a bi-monthly 
newsletter with over 16% subscribers. Then, with 
many stations on-the-air, the printed newsletter 
gave way to electronic messages posted on packet=- 
radio bulletin boards. There now 3 bulletin 
boards operated by members of SLAPR. 


The network around St. Louis consists of about 36 
stations, and digipeaters link the group as far 
north as Peoria, IL. Recently, one St. Louio 
station was able to connect to a station in Ames, 
Iowa. 


For further information about SLAPR, contact: 
SLAPR 
c/o Spencer T. Branham 
9926 Levis and Clark Blvd. 
St. Louis, MO 63136. 


WEW FLORSDA PACKET CLUB 


The organizing meeting of the Central Florida 
Packet Association wa6 held on August 22. J im 
Diggs, K4AHO; J oseph Leavitt, KF4WM; Larry 
Gilbreath, WD4BMN; Ed Cox, W#RAO; and Butch Weber, 
WA4GIF formed the club. There are 19 charter 
memberships available to organizations or 
individuals. For further information, contact 

Jim Diggs, K4AHO 

7966 Plunkett Ave. 

Orlando, FL 32819. 


via FADCA>BEACOH 


ARRL DIGITAL COMMUNICATIONS COMMITTEE 


At a meeting in 1981, the ARRL Board of Directora 
asked then-ARRL President Harry Dannals to forr 
"an ad hoc committee to recommend standard6 for 
digital communication6 in the Amateur Radio 
Service.” Preoident Dannais and the next ARRL 
President, Vic Clark, soon completed the formation 
of the ARRL Ad Boc Committee on Digital 
Communication. The “Digital Committee” advises 
the ARRL Board of Director6 on matter6 concerning 
digital communications, and ha6 been involved in 
such issues as the legalization of AMTOR, and the 
standardization of packet-radio protocols. 


If you have information that you think ahould be 
brought to the attention of the Digital Committee, 
contact one of the following Committee members: 
Paul Rinaldo, W4RI (Chairman); Dennis Connors, 


KD28; Terry Fox, WB4JFI; Douglas Lockhart, VE7APU; 
Welly Linstruth, WA6JPR; Dr. Henry S. Magauski, 
KA6M; Paul Newland, AD7I; Eric Scace, K3NA. The 
members of the Digital Committee are amateurs with 
experience and expertise in digital 
communications. When requesting information or 
guidance from one of them, remember that they are 
all volunteers, and they do not have time to 
answer every question and discuss every issue. 


DIGITAL COMMITTEE MEETING PREVIEW 


During the weekend of September 15 and 16, the 
Digital Committee will meet at ARRL Headquarters 
to discuss several topics of interest to Gateway 
readers. 


The first order of business at this meeting will 
be to inspect and approve the specification of 
AX.25 Level Two (link level) put forth by Terry 
Pox, WB4JFI, of AMRAD. Approval of this 
specification by the Digital Committee is the last 
step necessary before the protocol is “officially” 
approved by the ARRL Board of Directors. The 
protocol described in this document is essentially 
the same as, and completely compatible with, the 
protocol that most of us use in every-day packet 
operation. Once this protocol has been made 
official, it will be published by the ARRL so that 
foreign Amateur societies, equipment manufacturers 
and digital experimenters will be able to work 
vith a rigorous definition of AX.25. 


The approval of AX.25 Level Two will probably be a 
routine matter, and most of the weekend will be 
devoted to discussion of network and internetwork 
protocol6 for Amateur Radio. A network protocol 
Manages communications between stations in the 
same local network, and is called a “Level 3a" 
protocol. An internetwork protocol manages 
communication6 among local networks, and is 
designated “Level 3b." 


The need for Level 3a is obvious to anyone who 
uses a crowded local network. Without Level 3a, 
stations that can’t hear each other use 
digipeaters to communicate. The digipeater is a 
simple device; if it hears a packet that it is to 
repeat, it repeats the packet. If that packet 
gets lost in a collision, the sending station must 
retransmit the packet, and the digipeater must 
repeat the packet again. When Level 8a is 
implemented, some digipeaters will be replaced by 
network controllers. These network controllers 
will not only forward packets, but make sure that 
the forwarded packets are delivered. If a packet 
forwarded from a network controller gets 
destroyed, the network controller, and not the 
sending station, will retransmit the packet. This 
should greatly enhance local communications by 
reducing the number of collisions on the network. 


The need for a Level 3b protocol is equally 


obvious. We want to send packets from coast to 
coast and from country to country. It is the 
internet layer, which forwards packet6 through 
series Of local networks, that will allow us to do 
this . 


Proposals and comments presented at the upcoming 
Digital Committee meeting will have direct effect 
on the development of amateur packet radio. The 
next issue of Gateway will summarize the Digital 
Committee meeting. 


ATLANTA PACKET REPEATER 


In late August, a duplex repeater dedicated to 
packet radio began operation on Black Jack 
Mountain near Atlanta, GA. The repeater 
operates on 146.13/.73 MHz. 

Via Sandy Donahue, WA4ABY 


CITS/ARRL TECHNICAL SEMINAR 


The Central Iowa Technical Society (CITS) will 
host the first annual ARRL Iowa Section technical 
seminar on September 22 in Des Moines. The 
seminar runs from 9:99 AM to 5:¢¢ PM, and will 
feature packet radio. 


Lyle Johnson, WA7GXD, Tucson Amateur Packet Radio 
(TAPR) president, will discuss development of TAPR 
terminal node controller (TNC) software and TAPR 
participation in current linking discussions. 
Lyle was one of the prime-movers during the 
design, testing, and production of the TAPR TNC. 
He received the 1984 Dayton Hamvention Technical 
Achievement Award for his work on the TNC project. 


Jeff Ward, K8KA, from the ARRL will give an 
overview of ARRL technical activities, with 
emphasis on recent digital communications 
projects. 


John Maurer, NAGS, of CITS, will present last- 
minute details on the CITS computer bulletin board 
system (CBBS) hardware and software. John, and 
Dave Huffman, KA@DNB, will also discuss progress 
toward an inexpensive packet-radio link management 
unit based on surplus microcomputer hardware. 


Finally, Ralph Wallio, W@RPK, will review the 
background, success, and future plans associated 
with packet-radio meteor-scatter communications. 


Proceedings will be made available after the 
conference. For more information, contact Ralph 
Wallio, W@RPK, CITS President, at (515)961-6446. 
via WORPK. 


METEOR BURST SUCCESS 


Ralph Wallio, W@RPK, of Indianola, Iowa, and 
Robert Carpenter, W30TC, of Rockville, Maryland, 
have been making routine packet-radio contacts via 
6-meter meteor-burst propagation. W@RPK uses 25¢ 
W into a S-element beam, and W30TC uses 15$ W and 
a6-element beam. Both stations are using AFSK FM 
at 126@ bauds. In order to take advantage of 
short meteor trails, packets are limited to 39 or 
49 characters of information. Taking overhead 
(addressing and other protocol information) into 
consideration, the information packets are between 
326 and 388 ms long. Acknowledgement packets are 
126 ms long. This should allow transfer of 
information on meteor trails with duration between 
449and 509 ms. Unfortunately, WORPK’s 
transceiver need6 16@ ms for T/R switching, 
bringing the necessary trail duration to about 6%9 
ms. Even though this system is not optimized, 
several long file6 were transferred. Throughput 
was about 1 bit/s. 


Work is now under way to achieve better 
throughput. Possible improvements include more 
efficient modulation techniques, higher output 
power and special protocols. Via W30TC. 


SOUTHERN CALIFORNIA 23-C™ BAND PLAN 


On August 25, the Southern California Repeater and 
Remote Base Association (SCRRBA) hosted a public 
meeting to discuss a new southern California band 
plan for the 23-cm band. Each group of 23-cm 
users, including packet-radio experimenters, chose 
a spokesman. After a +-hour discussion, a band 
plan was agreed upon. 


Those sections of the band allOcated to digital 
communications are listed below. 


Narrow-band FM and narrow-band 
digital (<5¢-kHz bandwidth). 
Widebanddigital (>50Q-kHz 
bandwidth). 


1246-1248 
1248-1251.5 


1258-1260 Narrow-band FM and narrow-band 
digital (<5$-kHz bandwidth). 
1260-1270 Satellite uplink and non- 
coordinated s imp lex (inc lud ing 
experimental wideband techniques). 
1288-1294 Non-coordinated simplex (inc lud ing 
experimental wideband techniques). 
1297-1300 Widebanddigital (>5Q0Q-kHz 


bandwidth). 


This band plan was prepared specifically for use 
in the southern California geographical region. 
It was unanimously approved by the representatives 
of ALL the users groups. This band plan takes 
effect immediately, and will be reviewed after 


three years. 


Since the southern California region leads other 
areas of the country in 23-cm band activity, 
SCRRBA believe6 that the new band plan may be of 
use to other coordination councils. It is 
important that digital users represent themselves 
at band-planning meetings, so that the needs of 
wideband digital communications will be met over 
the next few years. Via SCRRBA news release. 


PACKET-RADIO WEATHER NETWORK? 


As packet-radio networks grow, and operators begin 
to tire of real-time, RTTY-like contacts, the 


search will start for applications for this new 
communications tool. A letter recently received 


by Paul Rinaldo, W4RI, from Dr. Fred Decker, U. S. 
Deputy Assistant Secretary for Education, points 
out that a packet-radio network would be a great 
means of distributing weather information 
collected at amateur meteorological stations. 


Many schools around the country have student-run 
weather stations and meteorology clubs. Some of 
these schools also have amateur radio clubs and 
stat ions. What better way to introduce interested 
and capable students to amateur radio (and packet 
radio) than by using amateur packet networks to 
connect amateur weather stations? Such a project 
would blend the natural sciences, computers and 
amateur radio into an interesting and useful 
whole. It might bring some young people in 
contact with amateur radio, and it certainly would 
provide “users” for our growing packet network. 


If you are interested in meteorology and packet 
radio, or if you are just interested in packet 


radio and public service, contact Gateway for 
further information about this interesting 


possibility. 


EMERGENCY COMMUNICATIONS 


On July 31, members of the Florida Amateur Digital 
Communications Association (FADCA) conducted a 
demonstration of packet-radio emergency 
communications. At the request of the Martin 
County Public Safety Department, stations were 
placed at the Mart in County Emergency Operations 
Center (EOC), the Dade County EOC, St. Lucie, Palm 
Beach, and the National Hurricane Center in Miami. 
Traffic was successfully passed among all 
stations. As a result of the demonstration, the 
Martin County EOC will be installing a TNC and a 
two-meter rig. 


If you are planning emergency operation, the FADCA 
team advises that a standard message format is 
needed, and each station should be able to print 
and buffer messages. 

Via FADCA>BEACON 


TAPR SOFTWARE UPDATES 


In the first issue of Gateway, Harold Price, NK6K, 
a member of TAPR’s softwar2 development team, 
discussed some of the projects under way at TAPR. 
One of the projects mentioned was TAPR TNC 
software Version 4.0. When asked about the status 
of this software, Harold made the following 
comments: 


“The scope of TAPR software release version 4.0 
may change as a result of the Digital Committee 
meeting in mid-September. Version 4.0 is intended 
to allow groups to experiment with network layer 
protocols, and may require some tweaking based on 
what class ot network layer protocol receives the 
most support during the meeting. We remain 
convinced that no matter what approach is taken, a 
TNC with the ability to maintain multiple 
connections at level two will be a big advantage 
to network developers. 


“There are a number of fixes and extensions that 
are desirable outside the context of Version 4.9. 
A report and request for comments was released to 
the electronic networks in late August, and will 
appear in the next edition of the TAPR Packet 
Status Register (PSR). If Version 4.0 is pushed 
back, these fixes and extensions will be released 
as Version 3.4. No date has been set for these 
releases [So don’t bother them about it. Ed.], but 
they are high priority items.” From NK6K 


YOSAT DATA COMMUNICATIONS EXPERIMENT 


Harold Price, NK6K, also shed some light on the 
status of the UOSAT-OSCAR 11 Data Communications 
Experiment (DCE). This is an experimental store- 
and-forward digital communications system on board 
uo-l1. The primary objectives of the DCE are to 
test satellite and ground station hardware and 
software for the upcoming PACSAT mission. 


Harold says: “The Digital Communications 
Experiment on board UOSAT-OSCAR 11 is still in the 
spacecraft command loop. Once the ground station 
in Los Angeles is fully commissioned, procedures 
will be worked out that allow testing of the DCE 
while still maintaining a high reliability path to 
the satellite’s command system. The DCE is 
currently being used to bypass a_ failed component 
in one of the command uplinks.” From NK6K 


PACKET RADIO AT THR, YORK HAMFEST 


On September 22, Jon Bloom, KE3Z, an ARRL 
Laboratory Engineer, will give a taik on packet 
radio at the York, PA Hamfest. The hamfest is 
sponsored by several York-area amateur-radio 
clubs, and take6 place September 22 and 23 at the 
York Fairgrounds. 


SPECIAL SERVICE CLUBS 


If you are receiving Gateway because you are an 
official of an SSC, please make full use of your 
complimentary subscription. Pass Gateway along to 
member6 of your club who might be interested in 
digital communications. Use any interesting 
Gateway-items in your club newsletter. If your 
club takes particular interest in packet radio, 
contact one of the packet-radio clubs listed in 
the first issue of Gateway. Members of those 
club6 are usually willing to give demonstrations 
for interested groups. 
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ARRL DIGITAL COMMITTEE MEETING 


The ARRL Ad Hoc Committee on Amateur Radio Digital 
Communication met in Newington, Connecticut on 
September 14, 15 and 16. [See issue 3 of Gateway 
for background on the Digital Committee.] Twenty 
packet-radio enthusiasts (committee members and 
observers) were present for the meeting. The 
group addressed the state of amateur packet radio; 
link-layer protocols; and approaches to packet- 
radio networking. 


The following items summarize the results of the 
weekend’s meet ings. 


DIGITAL COMMITTEE APPROVES _AX.25 SPECIFICATION 


During its meeting on September 15, the ARRL Ad 
Hoc Committee on Amateur Radio Digital 
Communication approved a specification of the 
AX.25 link-level protocol. This clears the way 
for submission of the protocol to the ARRL Board 
of Directors for their approval. 


The approved specification of AX.25 was written by 
Terry Fox, WB4JFI. The protocol is essentially 
the same as that implemented on all of the TNCs 
now on the air. Major changes from previous 
versions of AX.25 concern the poll/final (P/F) bit 
and multiple digipeaters. The specification 
includes the P/F bit resolution proposed by Phil 
Karn, KA9Q [See July, 1984 QEX]. The use of 
multiple digipeaters, as permitted on most 
available TNCs, is now part of the “official” 
protocol. Neither of these changes will make the 
specified protocol incompatible with existing 
implementat ions. 


The ARRL Board of Directors will consider AX.25 at 
its next meeting, in October of this year. Board 
of Directors’ approval will create a published, 
international standard protocol for amateur packet 
radio. With such a standard in existence, 
commercial manufacturers will be able to design 
products for packet radio, confident that their 
products will be compatible with others’. 


23-CM BAND PLAN COMMENTS. 


The Digital Committee also considered the matter 
of UHF band plans. After some discussion, the 
committee endorsed the ARRL VHF/UHF Advisory 
Committee (WAC) band plans for both 23 cm and 33 
cm. The committee noted that the Southern 
California Repeater and Remote Base Association 
(SCRRBA) 23-cm band plan also includes sufficient 
frequency allocations for digital communication. 
The digital allocation in the SCRRBA band plan is 


not on the same frequency as that in the ARRL band 
plan, but this should only cause slight problems 
on links going into and out of Southern 
California. 


PACKET-RADIO NETWORKING 


The next step in the development of amateur packet 
radio is the specification and implementation of a 
network-layer protocol. The network layer is 
responsible for routing packets from their 
originator to their addressee through a number of 
intermediate stations. There are currently two 
network protocols being proposed for amateur 
packet radio. To help decide which of these 
protocols is better for amateurs, the Digital 
Committee had a “brainstorming” session. The 
session provided an interesting look at the future 
of amateur packet radio. Some of the points made 
during the discussion follow: 


0 A user should need only a TNC to access the 


network. 

0 The network should be easy to operate. 

0 The network should support a wide variety of 
media (HF, VHF, microwaves, meteor scatter, 
etc.). 

0 The network should remain amateur in spirit. 

0 The network should work when commercial 


networks are down; in the event of 
emergency, the network should still be 
available. 


0 Network users should be able to specify their 
needs (for example, a choice of speed over 
reliability). 


0 The network should be able to resist jammers. 


0 The network should be able to take advantage 
of new stations when they come on the air, 
and should not be crippled by stations 
leaving the air, 


0 The network should support traditional 
amateur operating modes, rather than forcing 
amateurs to change their habits. 


0 Both real-time and store-and-forward 
operation should be supported. 


0 Controlled broadcast, or alert should be 
available. 


0 Roundtable operation should be supported. 


o There should be a network directory available 
on the air. 


° Fault detection and isolation should be easy. 


re) The network should function well in various 
geographical regions. 


re) There should be a mechanism for monitoring 
the performance of the network. 


0) There should be no user “passwords” or other 
“authentication.” 
° The network should be data transparent; 


whatever data is sent from the source should 
be received unchanged by the destination. 


° The network should be global. 


o The goals set for the network should be 
attainable within the limited, amateur 
resources available. 


This is an ambitious set of goals. The Digital 
Committee feels that, given the proper approach 
and efficient use of available resources, these 
goals are attainable. 


After the brainstorming session, the committee 
heard tutorials on the two proposed network 
approaches, data&rams and_virtual circuits. A 
very brief summary of each approach follows. 


Each packet sent through a datagram network is 
routed independently of any preceding or following 
packets. This routing system is very robust; if 
stations join the network, they can be immediately 
taken advantage of. If stations leave the network 
(as long as a path exists from the source station 
to the destination station) communications will 
not be interrupted. There is a price which must 
be paid for this robustness: each packet must 
contain extensive information needed for routing. 
The datagram protocol being advanced for amateur 
packet radio is the Defense Advanced Research 
Projects Agency (DARPA) Internet Protocol (IP). 


In a virtual-circuit network, a route is 
established between the calling station and the 
called station at the beginning of a QSO. This 
route is called a virtual circuit or a virtual 
connection, and is used by all of the packets in 
the QSO. Only the first or call-setup packet must 
contain complete routing information. Once the 
virtual circuit is established, subsequent packets 
need only include a_virtual-circuit number. If 
one of the stations in the virtual circuit becomes 
unable to handle traffic, another call-setup 
packet must be sent, and another virtual circuit 
set up. Note that most packets will not be call- 
setup packets, and will contain minimal routing 
information. This is one of the advantages of the 
virtual-circuit approach to networking. The 
virtual circuit protocol proposed for amateur use 
is called AX.25, and is set forth by Terry Fox, 
WB4JFI, in the Third ARRL. Amateur Radio Computer 
Networking Conference proceedings. 


These descriptions do not fully describe the 
protocols under consideration, nor do theycapture 
the scope of the discussions that took place 
during the Digital Committee meeting. After 
almost two days of discussion, there were still 
proponents of virtual circuits, proponents of 


datagrams, and a number of undecided individuals. 


The Digital Committee has no desire to force a 
protocol upon any group. Because of the number of 
people in the undecided camp and the number of 
points in favor of each type of protocol the 
committee decided that the packet community would 
best be served by a period of experimentation, 
during which both datagrams and virtual circuits 
would be implemented and tested. 


Several members of the committee stressed the 
importance of implementing the protocols in a 
transportable high-level computer language. This 
would allow the programs that are developed to be 
run on many computers. The people who are going 
to be doing the programming decided to use the "C" 
programming language. In order to test the two 
protocol implementations, they must operate in the 
Same environment. The test environment chosen by 
the committee is the Xerox 820 computer, modified 
to use an HDLC chip and run at 4 MHz. These 
decisions are not meant to stifle network protocol 
experiments. They were intended to foster program 
transportability, and to provide a common 
environment for testing protocol performance. 


The identification of network objectives, the 
discussion of protocols, and the formulation of an 
experimental approach are the first steps toward 
the implementation of a world-wide packet-radio 
network. If you are interested in the network 
protocol experiments, contact a member of the ARRL 
Digital Committee [See Gateway f38.1 and get 
started! 


EUROPEAN PACKET ACTIVITY 


Several European observers were present for the 
ARRL Digital committee meeting. They were: 
Hanspeter Kuhlen, DK1YQ, from AMSAT-DL; Ian Wade, 
G3NRW, from the British Amateur Radio Teleprinter 
Group (BARTG); John Sager, G80NH from the RSGB; 
and Alan Jones, G8WJM, from the Cambridge Computer 
Labs. The primary duty of these observers was to 
learn about the state of amateur packet radio in 
the U.S., but they also provided us with some news 
about packet radio overseas. 


Germany: In West Germany, several TAPR TNCs have 
made it through customs into the hands of the new 
Bavarian Packet Radio Group. There should be 
twenty or more packet stations on in West Germany 
by the time you read this. Unfortunately, there 
are some German regulations that will slow the 
development of packet networks; no two repeaters 
may be linked together, and no third-party traffic 
may be passed. Hanspeter was confident that these 
hurdles could be overcome. For more informat ion 
on the Bavarian Packet Radio Group, contact: 

Thomas Hieselbach, DL2MDE 

Narzissenweg 19 

D-8031 WESSLTNG 

W-Germany. 


England: The RSGB, in conjunction with BARTG, has 
formed a Packet Radio Working Party. The aims of 
the group, chaired by Dr. Dain Evans, G3RPE, are : 
to clarify what is meant by Packet Radio in the 
amateur context; to determine what form Packet 
Radio is likely to take in the UK, and to compare 
this with activity in other countries; to 
determine how packet repeater proposals are to be 
handled; and to determine the requirements for 


possible changes of the license regulaticns to 
exploit the capabilities of Packet Radio to the 
full. The Working Party has held two meetings, 
and adopted AX.25 as a standard for the UK. The 
BARTG newsletter_Datacom is a good source of 
information on packet radio in the UK. Write: 

Ian Wade, G3NRW 

7 Daubeney Close 

Har ling ton 

Dunstable 

Bedfordshire 

LU5 6NF 

UK. 
There are already thirteen stations running AX.25 
packet radio in the UK, and several dozen others 
are actively interested. Expect to hear UK 
packet stations on Oscar-10 or HF any day now. 

Via DATACOM 


PACKET RADIO. ON JAPANESE SATELLITE 


Sometime between 1985 and 1987, the Japan Amateur 
Radio League (JARL) and JAMSAT will be launching 
the first all-Japanese amateur satellite, JAS-1. 
Along with a Mode-J transponder, JAS-] will carry 
a store-and-forward packet-radio transponder. The 
packet-radio transponder will operate at 1299 
bauds, FSK, with an uplink in the Z-meter band, 
and a downlink in the 7@-cm band. The designers 
of the satellite have agreed to use the AX.25 
link-layer protocol, strengthening the protocol’s 
standing as an international standard. 


If the amateur satellite fraternity is able to 
fund the launch of a Phase-III C satellite, that 
satellite might carry a packet radio transponder. 
The ability of the satellite to carry such a 
transponder will be regulated by three factors: 
kick motor capacity, space available, and power 
available. If the proposed steam-propelled kick 
motor is used, there should be both the motor 
capacity and space available to launch a digital 
transponder. The power-consumption limits placed 
on the design of the transponder would make most 
of the existing technology useless, since existing 
high-level data link control (HDLC) chips draw too 
much current for satellite application. The use 
of software to transmit and receive packets 
through CMOS serial I/O devices is under 
considerat ion. A packet transponder for Phase-III 
C is not a high-priority item for AMSAT-DL, but it 
is under consideration. Via DK1YQ 


PACKET COLUMN IN RADIOSPORTIRG 


Puri Blanarovich, VE3BMV is hoping to start a new 
amateur-radio magazine called Radiosporting. He 
plans to make it “for active radioamateurs, filled 
with timely information that would be of interest 
to many involved in operating and competitive 


aspects of amateur radio.” One of the columns in 
Radiosporting will be devoted to RTTY, AMTOR and 
packet radio. If you are interested in 


subscribing to Radiosport, or contributing to its 
packet column, contact: 

RADIOSPORTXNG 

Box 65 

Don Mills, ON, M3C 2R6 

CANADA . 


MORE NEWS ON HLGH-SPEED PACKETS 


We received the following letter from Richard 
Bisbey II, NG6Q: 


“The Information Sciences Institute Amateur Radio 
Group (WB6MXZ) has been on the air with a 56 Kb 
packet radio system since December, 1983. The 
equipment consists of 8$88-based controllers using 
the Zilog 8530 SCC chip and frequency agile 1§=- 
watt FSK transmitters and receivers. The 
controller supports serial, parallel, and Ethernet 
connected devices. Assembled controllers cost 
approximately $650. The system uses standard 
INTERNET (IP/TCP) protocol, and in addition to 
supporting simple link level connections, supports 
internetworking as well as numerous high-level 
protocols such as TELNET, File Transfer (FTP), 
Mail (SMTP), Multi-Media Mail (MMM,MPM), Graphics 
(GP), Packet Voice (NVP), and Remote Virtual Disk 
(RVD). The hardware and software can support data 
rates as high as 1 Mb, well in excess of the 
current amateur limit of 56 Kb. 


“Previous packet radio accomplishments by ISI 
amateurs include a March 1982 demonstration of 
transcontinental packet radio internetworking 
between an aircraft flying above Los Angeles and a 
fixed station in Virginia, and a November, 1982, 
demonstration of intercontinental internetwork 
packet radio communications between Los Angeles, 
California and The Hague, Netherlands using 
Intelsat-4A. The ISI group is currently 
developing a low-cost spread-spectrum system with 
capabilities similar to the current non-spread 
system.” 


SEATTLE, WA PACKET CLUB 


The Seattle-Tacoma area packet radio users 
recently decided to become a formal organization. 
The actual formation of the club will take place 
October 13, 1984, at 139@ Pacific Time in the 
Boeing Employees’ Amateur Radio Society 
meeting house. The club constitution will be a 
slightly modified version of the NEPRA 
constitution. The first large-scale goal of the 
club will be linking of the Seattle-Tacoma-Everett 
area to Vancouver, BC; Portland, OR; Spokane, WA; 
and Moscow, ID. Via KD7UW 


PACKET. RADIO. IN GEORGIA 


The Georgia Radio Amateur Packet Enthusiasts 
(GRAPES) club was formed on September 14. Their 
network name? GRAPEVINE, of course. They are 
interested in setting up repeaters to link Georgia 
with the Carolinas, Florida, Alabama and 
Tennessee. They would like to hear from packeteers 
in those areas. One possibility that they are 
examining is a repeater location on Brasstown 
Bald, a 4,784-ft mountain on the northern Georgia 
border. For informat ion, contact: 

Dennis Barrow, WB4GQX 

Rte 7 Heard Road 


Cumming , GA 30130. Via W4RI 


ABSTRACTS. 


As space permits, and interesting articles come to 
our attention, Gateway will print abstracts of 
articles found in other journals and newsletters. 


If you know of an article that should be 
abstracted, drop us a note and a copy of the 
article. 


"HF Packet Frequency Specification,” by John 
Langner, WB20S8Z; NEPRA Packetear, Issue 14. This 
one-pager addresses the problem of frequency 
specification for FSH stations on HF. It proposes 
that the radio frequency midway between the mark 
and space frequencies be used when discussing the 
operating frequency of such stations. 


“Routing Strategies in Computer Networks,” by 
Hsieh and Gitman; Computer, June, 1984. This 
article addresses the question of routing. It 
sets forth some algorithms for determining the 
best route from one node to another, and discusses 
the application of these algorithms to various 
types of computer networks. Since it addresses 
routing in both datagram and virtual-circuit 
networks, this article is particularly interesting 
to people concerned with amateur packet-radio 
networking. 
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IOWA SECTION TECHNICAL SEMINAR 


There was not enough room in Gateway #4 for a 
report on my trip to Iowa, September 21 and 22, 
for the Central Iowa Technical Society’s lowa 
Section Technica 1 Seminar. The seminar covered 
many technical topicsbut concentrated on packet 
radio. 


Lyle Johnson, WA7GXD, president of Tucson Amateur 
Packet Radio (TAPR), gave a well-received 
*presentation on packet-radio linking and the 
outcome of the ARRL Digital Committee meeting. 
One of Lyle’s points bears repitition: We have 
begun to experience an unfortunate problem in 
packet radio. People who would otherwise be 
experimenting with protocols, or modems, or TNCs 
are not, because they have heard that "TAPR is 
going to do it.” Lyle is worried that the success 
of the TAPR TNC project is keeping others from 
experimenting in packet radio. It must be 
stressed that packet radio needs experimentation. 
The question of what networking protocol is best 
for amateur packet radio is not going to be 
answered by the Digital Committee, TAPR or any 
other single organization. The question is going 
to be answered by experimentation. If you want to 
experiment, do it. Who knows? It might be your 
software or hardware that answers a critical 
packet-networking question. 


While I was in Iowa, I got to look at the CITS 
club station that is taking part in packet meteor- 
scatter experiments. It is interesting to note 
that there was no expensive equipment used in the 
station. A crew from CITS salvaged an o ld, 
surplus Motorola VHF rig, built and erected a six= 
meter beam, and interfaced it all to a TAPR TNC. 
The only parts that had to be purchased for the 
project were six-meter crystals. That_is ham 
radio. 


VHF AND UHE EXPERIMENTATION 


Giving a talk at the Mid-Atlantic States VHF 
Conference, I was reminded that packet radio, 
while it makes heavy use of digital technology, 
has a lot to offer amateurs who are not interested 
in computers. If you are a VHF or UHF 
experimenter, you will find that packet radio is 
fertile ground for VHF and UHF applications. In 
many parts of the country, the two-meter band is 
full, and the 22$-MHz band is not far behind. 
This crowding, and transmission speed restrictions 
on the lower VHF bands, will force packet radio 
into the UHF and microwave spectrum. So, if you 
are interested in VHF and UHF design, maybe your 
local packet group can give you some project 
ideas . 
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EASTNET KEEPS GROWING 


The east-coast packet radio link has taken one 
more step toward reality. The MD/DC/VA to 
Philadelphia link is improving by the day. Joe 
Fisher, KC2TN, should get a new antenna up this 
weekend which will make the path as solid as a 
rock. We have been linking the packet bulletin 
board systems (PBBSs) at W3IWI and WB2MNF almost 
nightly. Until we get Level 3 protocols up and 
running, it looks’ like linked PBBSs will 
provide a store-and-forward capability not unlike 
what we will have with PACSAT. Both Tom Clark, 
W3IWI and Jon Pearce, WB2MNF, are running PBBSs 
with Xerox 829 computers and W9RLI PBBS 
software. Prom W3IWI 


NETWORKING IN THE MIDWEST 


In late September,Chicago, IL,and St.Louis, MO 
were connected by VHF packet radio. The path is 
in excess of 3$$ miles, and there are no mountain 
tops to take advantage of. Congratulations to the 
more than half-dozen stations involved in the 
digipeating. Via WBOFLW 


UO-11 DATA COMMUNICATIONS EXPERIMENT 


During the week of October 1, the JoSat command 
station in Surrey, England conducted tests and 
experiments on the data communications experiment 
(DCE) aboard U0-11l. Tests of the VHF uplink and 
UHF downlink for the DCE culminated with 
successfull reception of 969@-bit/s data on 
Friday, October 5. Congratulations to the team at 
Surrey and the rest of the crew responsible for 
the DCE! We also would like to wish UVoSat-OSCAR 9 
a happy third birthday. UO-9 was launched on 
October 6, 1981, and is still in service. 


PACKET RADIO FOR EMERGENCY COORDINATORS 


The new ARRL_ Emergency Coordinator’s Handbook, 
with a 2@-page chapter on packet radio, is 
available for $5.6@ from the ARRL. This book is 
“intended to help you acquire, develop and refine 
the skills which you need to function effectively 
in serving the public through Amateur Radio 
communications.” The chapter on packet radio 
should make those in the-Amateur Radio Emergency 
Service (ARES) aware of the traffic handling and 
organizing capability of packet radio. If your 
packet club is looking for somewhere to put on a 
demonstration, try an ARES meeting. If you are an 
ARES organization looking for an interesting 
meeting program, contact a nearby packet club. 


MORE ON A POSSIBLE. PACKET WEATHER NET 


Fred W. Decker, W7ANX, U.S. Deputy Assistant 
Secretary for Education, has said previously that 
he believes packet radio and amateur meteorology 
can be united to form a. packet-radio weather 
network [See Gateway #3.]. Such a network would 
provide some users for the growing amateur packet 
network, and perhaps generate some interest in 
amateur radio among amateur meteorologists. In a 
paper delivered at the First International 
Conference on School and Popular Meterological 
Education, Dr. Decker goes on to say: 


"(1) Packet radio communication has emerged for 
amateur use as new manufacturers offer equipment 
enab 1 ing amateurs to communicate using their 
computers and [VHF radio equipment]. (2) 
Repeaters have recently carried packet signals 400 
miles in 5 repeater jumps. This opens the 
possibility of local networks exchanging data at 
substantial distances. (3) Weather sensors 
feeding computers and thereby archiving data for 
interrogation by packet radio have come on the 
market from at least two firms seeing the 
potential in computerized popular meteorology 
(Heath Co. and Vaisala). (4) The drive to “Save 
226" among radio amateurs seeks to populate the 
allocated 22$-MHz amateur radio band and thereby 
fend off commercial intrusion, and the belief 
grows that weather amateurs and schools can help 
this cause by adopting this band (1 1/4 meters) 
for packet radio exchange of computerized school 
and amateur weather station data. With basic 
technical innovation completed, it remains 
necessary only to adopt convent ions...to maximize 
the ease of data intergchange..." 


This is an interesting project, and the fact that 
Dr. Decker has been discussing it with his 
col leagues has undoubtedly brought packet radio to 
the attention of many people in academia. Dr. 
Noel Petit, WBGVGI, of Augsburg College, has 
proposed to build a computerized weather network 
that would communicate via telephone. The cost of 
his weather stations, including computer, sensors 
and modem, is about $300. Perhaps, with the help 
of some packet-radio enthusiasts, Dr. Petit’s 
weather network can use packet radio. 


If you are interested in this project, or in 
giving an educational demonstration of packet 
radio’ contact: 


Dr. Noel Petit 

Suite 228-B 

511 11th Ave. S. 
Minneapolis, MN 55415, 


or 


Dr. Fred W. Decker 

Deputy Assistand Secretary for Education 
Suite 722, Brown Bldg. 

1294 19th Streed, NW 

Washington, DC, 26248. 


SOFTNET NEWS. 


We recently received an issue of Softnet News, the 
newsletter of the Softnet Users Group (S.U.G.). 
S.U.G. is a group experimenting with packet radio 
in Linkoping, Sweden. “The main concept behind 
SOFTNET is that all packets are considered to be 


programs in a network language. These programs 
are interpreted in the nodes as soon as they 
arrive... This approach makes it possible for a 
user to define his own high level services like 
datagrams, virtual calls, file transfers and 
mailboxes.” [From "SOFTNET - An Approach to High 
Level Packet Communication“, Second ARRL._Computer 
Networking _Conference. | 


The SOFTNET approach could be used, with the AK.25 
link protocol, to provide network services in the 
growing North American packet network. 


SOFTNET nodes are currently implemented on four PC 
boards, a SOFTNODE computer board, a SOFTMEM 
memory board, a SOFTLINK link and modem board, and 
a radio board. S.U.G. is now se 1 ling PC boards, 
PROMS, and software for SOFTNET nodes. The builder 
must supply the other components needed to 
populate the boards. Total cost is about $600 per 
node. Of particular interest to those of us who 
operate on 129$ bit/s local networks is the fact 
that SOFTLINK radios/modems run at 1$$ Kbit/s. 


The SOFTNET concept is primarily concerned with 
network and internetwork functions. The SOFTNET 
News contains two articles on network routing, 
searching and addressing. S.U.G. is a growing 
group, moving forward quickly with packet-radio 
network experimentation. Their progress is sure 
to help packet experimenters worldwide. 


For information, contact: SOFTNET Users Group 
Dept. of E.E. 
Linkoping University, 
S-581 83 Linkoping 
SWEDEN 


Via SOFTNET News 


TELEPORT STA INFORMATION 


The waiver for automatic teleport operation 
requested jointly by the ARRL and AMSAT should be 
issued about October 17. This special temporary 
authority (STA) allows the operation of unattended 
digital gateway stations for store-and-forward or 
real-time satellite links. For a complete 
description of the STA, see Gateway issue 2. Two 
more stations, N2EKH and Theodore Harris, N6I1IU, 
have been added to the list of participants, 
bringing the total number of authorized stations 
to 21. From WIUED 


TECHNICAL COORDINATORS AND PACKET 


The ARRL Technical Coordinators (TCs) answer 
technical questions, put on technical talks, and 
perform many technical functions within their ARRL 
section. Several notes in the fall issue of the 
Technical Coordinator news letter indicate that 
many TCs are interested in packet radio. Richard 
Regent, K9GDF, editor of the newsletter, has 
received the following comments from other TCs: 
“[Our] greatest successful TC program is talking 
about data communications,” and “[we have been] 
getting packet radio started by helping hams 
assemble and operate kits, and holding Z-meter 
packet nets.” 


If you are interested in finding out more about 
packet radio, contact the ARRL to get the name of 
your section’s TC. Via Technical Coordinator. 


NEBRASKA PACKET GROUP? 


Lyman Nelson, WBGIEN, is interested in forming a 
state-wide packet radio group in Nebraska. 
Contact: 


Lyman Nelson , WBGIEN 
Rt. 2 
Hooper, NE, 68031. 


Via Technical Coordinator. 


MODEM FILTER FROM EXAR 


“Pre liminary" data from the EXAR IC company about 
the XR-21¢3 FSK modem filter has just arrived at 
the ARRL. The device is designed to “perform the 
complete filtering function necessary for a Bell 
193 compatible modem.” The chip uses switched- 
capacitor technology to implement two 6-pole band- 
pass filters. One of the filters is centered at 
1176 Hz, and one centered at 2125 Hz. This chip 
might prove useful to those using the Bel 1 193 
protocol for packet radio on HF. Perhaps, by 
changing the time-base crysta 1, the passbands 
could be moved to other frequencies. If you 
experiment with this chip, send us a letter 
describing your results. Via W4RI. 


PACKET FREQUENCY COORDINATION 


We have received word from AMRAD president, Terry 
Fox, WB4JFI, that The Middle Atlantic Amateur FM 
and Repeater Council (TMARC), on September 24, 
designated the frequencies 145.91, 145.03 and 
145.95 MHz for primary coordination as packet- 
radio channe ls in their jurisdiction. TMARC 
covers Maryland, De laware and Northern Virginia. 
Via W4RI 


PACKET DISCUSSION AT THE TROPICAL HAMBOREE 


If you are going to be in Florida this spring 
(planning ahead?), be sure to attend the 1985 
Southeastern Division Convention/25th Annual 
Tropical Hamboree in Miami, Florida on February 2 
and 3. An all-day Packet Radio Seminar is 
tentatively planned for Sunday, the 3rd. Paul 
Rinaldo, W4RI, Manager of the ARRL Technical 
Department, and Lyle Johnson, WA7GXD, president of 
Tucson Amateur Packet Radio, are scheduled to 
attend the seminar. More information, and a firm 
schedule for the seminar will be available in 
December. Via Dade Radio Club, Inc. 


DATA BASE OF PACKET USERS. 
Dear Packet Radio Enthusiasts; 


Several local Amateurs and I, representing 
Central Illinois Packet Radio User Society 
(CIPRUS) have started a to compile a directory 
of all stations who are also active’ on this 
fantastic new mode. After great acceptance and 
encouragement from the midwest as well as 
other areas, what initially was to be only a 
regional effort has been expanded to include the 
entire country. 


After giving a great deal of thought as to 
what the best method would be to compile such a 


data base, we decided to contact you, the 
packet radio clubs and other leaders in the area 
of packet radio. Most of what we have compiled 
to date has come through direct contact with 
individual stations. We learned that this 
method involved a lot of unnecessary paper work 
and correspondence that could be eliminated by 
contacting large organizations and groups. 


In order to contact as many stations as possible 
and to keep the costs down as much as practical 
we would like to propose the following: If 
you would send us a listing with all of the 
required information concerning your member 
stations along with a_ large manila s.a.s.e 
(several stamps please), we will, in turn, send 
out a compiled listing of active packet stations 
that you can photocopy and _ distribute to your 
membership. If you have your membership list 
in an IBM PC or compatible data base you can 
submit a diskette with the required information 
and have the compiled list returned on 
diskette. The data base is being maintained 
on an IBM XT in a dBase II file that can USC data 
from nearly any standard ASCII or WordStar text 
file (comma delimited prefered). 


Since many of us are not able to offer our 
services to the technical aspect of packet 
deve lopment, we view this project as one that 
will al low us to make a small contribution to the 
field of packet radio. We do not wish to 
become involved in the publishing business but 
rather to act only as a central point to compile 
and distribute data from you. We have been in 
contact with TAPR and have discussed the 
possiblity of enclosing a preprinted post card 
with every TAPR TNC shipped. This would al low 
the individual station to merely fill out the 
necessary blanks and return the card to us for 
inclusion in the directory. If you are aware of 
any other manufacturer of who would like to help 
this project, please have them contact us. 


In closing I would like to present the f0 11 owing 
points for your consideration and comment: 


1. This project is still in its infancy, with 
only about 250 stations listed to date; 
therefore we are open to suggestions as to 
what you feel should be included in such a 
directory. Speak up now while it is still 
relatively easy to modify the data base! 


2. We are not aware of any other group or 
individual who has decided to attempt a 
similar venture. If you know of such a 
group, please put them in contact with us 
so that we do not duplicate efforts. We 
don’t care who does it, just so long as it 
gets done by someone! 


3. The directory is currently being printed on a 
letter quality printer and duplicated on a 
photocopier. As the directory continues to 
grow so do the costs involved -- we are 
already making over 50 copies per month, with 
over 2¢ pages each. Professional printing 
is just around the corner. Therefore, since 
we are a nonprofit amateur radio club, we 
will not turn down any donations that you 
would like to make toward paper costs. 


4. The format that we are using is flexible 
but is being currently printed as fol lows: 


Listing #1 -- Alphabetic, by callsign: 


Callsign; Name; Address; Misc. Info(1) 
City, State, Zip; Misc. Info(2). 


Listing #2 -- Numeric, by zip code: 

Callsign; Name; City; State; Zip Code 

The "Misc. Info" columns may contain any items 
(approx. 15 characters) of special 


information that you may wish to include. 
Some ideas’ that have been used: frequency, 


OSCAR, mailbox, digipeater, 24-hour 
operation, grid square, and gateway 
operation. 

Thank You 


Gregory L. Smith = N9AGC 
c/o CIPRUS 

P.O. Box 4143 

Peoria, Illinois 61687 


[The above letter has been reproduced in full. 
Send any comments to Mr. Smith, and Gateway. | 
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TELEPORT STA GRANTED 


The FCC has granted the joint AMSAT/ARRL request 
for a special temporary authorization (STA) 
permitting operation of automatic digital 
teleport stations. (For complete discussion of 
this request, and a list of stations involved, see 
Gateway issues 1 and 5.) The FCC “concluded that 
the automatic relaying of digital messages between 
amateur stations on earth and amateur satellites 
via intermediary stations (stations in teleport 
operation) may contribute to the advancement of 
the technical and communication aspects of the art 
of radio.” 


The following sections of the Amateur Radio 
Service rules have been waived for authorized 
stations: 


“97.126 (a) is waived to permit an amateur 
station engaged in teleport operations to 
retransmit automatically the radio signals of 
other amateur radio stations. 


“97.126 (b) is waived to permit a remotely- 
control led amateur station engaged in tcleport 
operations to communicate with stations which 
are not shown on such a station’s network 
diagram. 


“97.79 (b) is waived to permit an amateur 
station engaged in teleport operations to be 
operated under automatic control without the 
presence of a control operator at a control 
point of the station; provided that devices 
are installed and procedures implemented to 
ensure compliance with the the Commission’s 
rules at all times; and, provided further that 
upon notification by the Commission of 
improper operation of a teleport station under 
automatic control, such automatic control 
shall be discontinued immediately until all 
deficiencies have been corrected.” 


Authorized stations may operate satellite uplinks 
and downlinks on 144-146 MHz and 435-438 MHz. 
Terrestrial inputs and outputs may be on any 
amateur frequency at or above 50 MHz where digital 
communications is permitted. 


This STA expires 180 days from October 18, 1984. 
Good luck to all stations involved. 


PACKET RADIO TELECONFERENCE RADTO NET 


"Packet Radio Overview and Prospective”will be 
the subject of the December 2nd North American 
Teleconference Radio New (TRN). This net, heard 
on over 150 gateway stations (mostly VHF 
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repeaters) across the U.S. and Canada and on the 
OSCAR 10 satellite, will explain what packet radio 
is, describe how to get started in it, point out 
the benefits to you, and outline the pitfalls to 
be avoided by the beginner and expert alike. The 
speakers on this TRN will be none other than Lyle 
Johnson, WA7GXD, and Harold Price, NK6K. 


Lyle is President of the Tucson Amateur Packet 
Radio Corporation (TAPR) and was one of the 
primary developers of the TAPR terminal node 
contro 1 ler (TNC) hardware. For his work in 
developing the TAPR TNC, Lyle was awarded the 1984 
Technical Exce 1 lence Award at Dayton. Looking to 
the future, Lyle is responsible for the processor 
design for the upcoming amateur packet satellite 
(PACSAT). He became active in packet radio in 
1981, the pioneer days for this new technology. 


Harold is a Director of TAPR and was on the team 
that designed the software for the TAPR TNC. He 
is also the AMSAT Project Manager for PACSAT. 
Harold is another packet-radio pioneer, having 
first become active in that technology in 1982. 


Packet radio offers opportunities for both the 
traditional communicator and for the experimenter. 
Learn about packet radio from two of its leading 
developers by tuning into TRN, Sunday, December 2, 
1984, at 6:00 PM CST (00002). For a complete list 
of gateway station locations and frequencies, 
write the TRN Manager, c/o Midway Amateur Radio 
Club, P.O. Box 1231, Kearney, NE 68847-1231 
(S.A.S.E. please, Canada excepted). Those of you 
on CompuServe HAMNET can find this list in the XA4 
data base. 


From Midway Amateur Radio Club 


GATEWAYS “DOWN UNDER." 


On September 1, from 20002 to 00002, VK2BVD and 
ZLIAOX maintained a fully “connected” 1200-bit/s 
data link between Sydney, Australia, and Auckland, 
New Zealand, on the 20-meter band. Propagation 
conditions were excellent, and there was little 
multi-path over the 2650-km, one-hop path. 
Substantial files were transferred in each 
direction. 


The following day, at the same time, an HF/VHF 
packet gateway was established using store-and- 
forward techniques with link-level 
acknowledgments. A total of 5 terminal node 
controllers (TNCs) and two computers were linked 
via 2-meter and 20-meter packet radio. Both 
ZLIAOX, in Auckland, and ZL3QL, in Cristchurch, 
were able to access the 2=meter local-area network 
(LAN) in Sydney. 


The gateway was in operation again on September 3, 
with a VHF beam orientation problem solved. ZLIAOX 
was able to connect to a host computer at VK2ZRQ 
and interactively operate the machine for over an 
hour. Both the HF and the VHF ports of the VK2BVD 
gateway functioned as expected. 


Other stations monitoring these activities 
included ZL3THJ, VK2AQG, VK2AYD, VK2XY, VK2ZXQ, 
and VK2KFJ. Via VK2BVD 


TRANSLATION OF GATEWAY 


As part of its continuing effort to promote 
digital communication modes, the Radio Club of 
Chile has been translating Gateway into Spanish. 
We received a photocopy of the Spanish edition. of 
the premier issue of Gateway, including an 
exce 1 lent trans lation of Jon Bloom’s “Introduction 
to Packet Radio.” If you need the Spanish edition 
of Gateway, contact 


Radio Club De Chile 

Departamento De Comunicaciones 

Centro De Documentacion 

Nataniel Cox 1054 = Santiago De Chile 


CHILE 
RF DESIGN TEAM 


A few Motorola engineers, members of the Florida 
Amateur Digital Communications Association 
(FADCA), want to design radios for amateur digital 
operation around 900 MHz (there will soon be an 
amateur assignment in this band). This group, 
chaired by Tom Kneisel, K4GFG, is looking for 
individuals to help them define the interface 
between their radio hardware and network 
controller hardware that is under development 
elsewhere. These are competent and interested 
engineers, just looking for a little more 
coordination and information. If you can help, 
contact 


Tom Kneisel, K4GFG 
1600 S.W. 115th Ave. 
Davie, FL 33325. 


Via FADCA>BEACON 


DEMONSTRATION IDEA 


If you want to demonstrate amateur radio to the 
public, why not try a shopping mall? The South 
Brevard (Florida) Amateur Radio Club set up a 
booth in a local shopping mall, and generated 
considerable interest in amateur radio. Packet 
radio played a part in this demonstration, with 
forty-two third-party messages handled via packet. 
Twelve of the messages were delivered by the 
SOUTHNET packet-radio network, and the rest were 
passed along to the All Florida CW Net, part of 
the National Traffic System. 


If you plan a packet demonstration (at a mall or 
anywhere else) remember to bring along plenty of 
backup equipment. The South Brevard group ran 
into strong electrical noise on their primary 
frequency, but since they had a couple of portable 
digipeaters in the mall parking lot, they were 


able to maintain solid connections to their 
message system. Via FADCA>BEACON 


TSRAC PACKETS 


In keeping with the feeling that Special Service 
Clubs (SSCs) should keep up with state-of-the-art 
techno logy, several member8 of the Triple-State8 
Amateur Radio Club (TSRAC) have been experimenting 
with packet radio. Don Knollinger, WB8ZTV, and 
Jay, KD8GL, have been communicating via packet, 
and prompting their fellow club member8 to join 
the “digital communications wave of the future.” 
TSRAC serves the area where Ohio, West Virginia, 
and Pennsylvania meet. Via TSRAC BET 


NEWS FROM ROCHESTER 


Fred Cupp, W2DUC, sent usa note giving the 
details of packet-radio activity in the Rochester, 
NY area. Fred says that there is now an active 
Rochester packet group with 7 stations on the air. 
Thursday night is packet activity night. Look for 
stations on the standard EASINET frequency, 145.01 
MHZ. 
Via W2DUC 


MT. ASCUTNEY PACKET CLUB 


Another new packet club is the Mt. Ascutney Packet 
Radio Association (MAPRA), which serves the area 
around Mt. Ascutney, NH. The group’s wide- 
coverage digipeater on 3,000-foot Mt. Ascutney is 
now a vital part of the growing EASTNET. For more 
information on MAPRA, contact 


Car 1 Breuning , N1CB 
54 Myrtle St. 
Newport, NH 03778. 


Via NEPRA PACKETEAR 


NETWORKING IN CALIFORNIA 


Packets from Sunnyvale (near San Fransisco) were 
received in Los Angeles and San Diego this week 
via several linked UHF repeaters, The path 
started on 146.58, went through two UHF hops 
(duplex audio repeaters), then out on 144.76, the 
alternate LA/SD packet channel. Packets from 
Oliver Barrett, KB6BA were heard by Harold Price, 
NK6K and Sumner Hansen, WB6YMH in Los Angeles, and 
by Mike Brock, WB6HHRV in San Diego. More 
experiments are planned for the near future, 
including getting some packets up the other 
direction. From NK6K 


UNIX ON EASTNET 


Phil Karn, KA9Q, has connected an IBM PC-XT, 
running UNIX System III, to his packet-radio 
station. UNIX is a powerful,’ multiuser, 
multitasking operating system, and Phil’s computer 
can be accessed simultaneously via telephone, 
packet radio, and operator console. Programs 
current ly avai lab le include a sate 11 ite tracking 
program, mai 1 programs, and a PBBS-style message 
facility. In the future, Phil hopes to connect 
the system to a TNC capable of supporting several 
level-2 connections, allowing simultaneous 


computer access to more than one packet-radio 
station. To use the system as a guest, simply 
type “guest” in response to the “login:" prompt, 
and type return when asked for a password. 


From KA9Q. 


MORE INFORMATION ON GRAPES 


We have received some more information on the 
Georgia Radio Amateur Packet Enthusiast Society 
(GRAPES) . The group is currently using a 
146.13/.73 full-duplex digital repeater located 
on Sweat Mountain. The call of the repeater is 
KD4NC-1. A PBBS is in the works. GRAPES is 
running a packet net on 145.54 at 8 P.M., Sundays. 
The club’s address is: 


GRAPES 
PO Box 223 
Conyers, GA 30208. 


Via GRAPEVINE 


CAPRA MEETING 


At its November meeting, the Chicago Area Packet 
Radio Association (CAPRA) will present a video 
tape on level-3 linking. The video tape was 
produced by members of the Central Iowa Technical 
Society (CITS), following the Iowa Section 
Technica 1 Seminar. Lyle Johnson, president of 
TAPR, and Jeff Ward, ARRL computer engineer, were 
the featured speakers at that seminar, and the 
video tape should be interesting to those looking 
forward to a true amateur packet-radio network. 
The CAPRA meeting is at 2:00 PM, November 10, in 
the Glenside Public Library, Glenside Hts., IL. 


Via HAMNET 


SOFTWARE AVAILABLE 


One of the reasons that packet radio has been able 
to grow very quickly is that many technically- 
skil led individuals have been willing to donate 
the fruits of their labors to the packet-radio 
community. One of the results of this nonprofit 
atmosphere is that packet bulletin board software 
and TNC software is available from several 
sources. Most of this software is in the public 
domain, and “se lls" for the price of disks or 
PROMs. Whenever possible, Gateway will print notes 
on the availability of public-domain software for 
packet radio. 


Lynn Taylor, WB6UUT, has written and debugged a 
very versatile packet bulletin board system (PBBS) 
program that runs on Apple II computers. Lynn’s 
software was designed to be as self-maintaining as 
possible and to squeeze every drop of storage out 
of two disk drives. It runs under UCSD Pascal, 
and requires a TAPR TNC, a Thunderware 
Thunderclock, a CCS 7710 serial port and two disk 
drives. The software is believed to be robust and 
bug-free. (As with all free software, however, 
the user is asked not to complain if bugs are 
found.) Lynn is willing to give the software to 
anyone who sends him 38 disks and sufficient 
postage to return them. Send them to: 


Lynn Taylor, WB6UUT 
463 Myrtle Street 
Laguna Beach, CA, 92651. 


If you have a program that you would like to make 
available to the packet-radio community, send 
Gateway a description of the program. 


BACKET_RAD1IO,WITH THE XEROX 820 


One of the decisions reached at the recent meeting 
of the ARRL Ad Hoc Committee on Amateur Radio 
Digital Communications was that the Xerox 820 
computer would be used as a benchmark and a 
testbed for packet-radio networking software. 
While it is possible to send and receive packets 
using the serial I/O (SIO) on the 820, this job 
can be done more easily if a high-level data-link 
controller (HDLC) chip is added to the computer. 
In a recent issue of FADCA>BEACON, Howard 
Goldstein, N2WX, outlined his design for such a 
modification to the 820. After the Digital 
committee meeting, Howard and some members of TAPR 
went to work producing a kit for this 
modification. The kit, now called the “FAD 
board,” is nearing completion; several prototype 
circuit boards will be finished by the time you 
read this. After Howard tests these first units, 
the circuit board will be made generally 
available. The FAD board is a “piggyback” board 
that replaces the Xerox 820 SIO with an 8530 HDLC 
chip, giving the user two RS-232-C or TTL HDLC 
ports. If you are interested in this circuit 
board, contact TAPR for ordering information. 


From G@WB9OFLW 


ABSTRACTS 


“How Good is Your Network Routing Protocol?,” by 
Hsieh and Gitman, Data Communications, May, 1984. 
This article investigates one of the most 
important aspects of packet-network design -- 
packet routing. There are many routing procedures 
under consideration for amateur packet networks, 
and it is interesting to read about what the 
professionals do. The article addresses route 
generation, link cost, packet ordering, and 
packet-forwarding operation. Two charts detail 
the routing strategies used by ARPANET, TYMNET, 
SNA, DATAPAC, and TELENET, and the effects that 
the chosen routing strategies have on those 
networks. 


“Implementing X.25 Communications Protocol,” by 
Eric L. Beser, Microsystems, June, October and 
November, 1984. This series of articles is a 
tutorial on X.25, the CCITT packet protocol on 
which the AX.25 amateur standard is based. The 
first article reviews layered network 
architecture, and introduces state machines and 
their use in protocol implementation. The second 
article discusses the design of Pascal software to 
implement X.25 with the Intel HDLC chips. The 
third article will discuss implementation of X.25 
using the Western Digital WD2511. If you are 
interested in designing a TNC, or just finding out 
how your TNC works, read this series of articles. 


“RF Modems ," by Hatchett and Howell, R. F. Design, 
September/October, 1984. This article is the 
first in a series of articles covering design and 
construction of RF modems. Several amateur groups 


are currently working on such modems, so this is a 
timely article. From the ground up, this first 
article addresses the basics of RF modems, system 
design trade-offs, types of modulation, and FSK 
transmitters. It then finishes off with a 
discussion of integrated circuits that are useful 
in RF modem design. For the experimenter, there 
is a block diagram and schematic for a 1.5 Kbits/s 
F SK modem. 


HOW IS GATEWAY DOING? 


As this issue of Gateway goes to print, there are 
more than 200 paying subscribers to the 
newsletter. Although I have no firm figures, I am 
sure that many other packeteers are receiving 
Gateway via electronic mail services or amateur 
packet-radio networks. I would like to thank you 
for your support, while reminding you that Gateway 
would like to hear from you about packet activity 
in your area. 


Jeff Ward, K8KA 
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ARRL BOARD MAKES PACKET-RADIO DECISIONS 


The ARRL Board of Directors met in Hartford, 
Connecticut, on October 25 and 26. Two matters of 
interest to packet-radio operators were discussed. 


First, the Board approved the AX.25 level-2 
protocol specification submitted by the ARRL Ad 
Hoc Committee on Amateur Radio Digital 
Communications . 


Second, the Board approved, “in substance,” a 
draft of a petition requesting amendment of 
amateur regulations to permit automatic control of 
digital stations operating above 30 MHz. This 
petition will now be made formal by the ARRL legal 
counsel and then submitted to the FCC for 
considerat ion. This rules change, should it be 
enacted, will clear up any doubt as to where 
packet-radio bulletin boards and other network 
servers fit into amateur regulations. 


CALL FOR PAPERS. 


The American Radio Relay League will hold its 
Fourth Amateur Radio Computer Networking 
Conference on March 30, 1985, in San Francisco, 
CA. The conference will be in cooperation with 
the West Coast Computer Faire being held March 30 
through April 2. 


Technical papers are invited on all aspects of 
amateur packet radio and other forms of Amateur 
Radio digital communications via terrestrial, 
ionospheric, meteor-scatter and satellite media 
including AMSAT-OSCAR 10 and PACSAT. Topics may 
include network and system architecture, proposed 
standards, hardware, software, protocols, 
modulation and encoding schemes, applications, and 
practical experience. 


The deadline for receipt of camera-ready papers is 
March 1, 1985. All papers should be mailed to 
Mar ian S. Anderson, WBIFSB, American Radio Relay 
League, 225 Main Street, Newington, CT 06111. If 
you plan to present a paper, please request an 
author’s kit and identify the title of your paper 
immediately. Proceedings will be sold at the 
conference and by mail from ARRL Hq. 


From W4kI 


CHERRYVILLE REPEATER ASSOCIATION 


We received the following letter from Charlie 
Kosman, WB2NQV: 


"T would like to call to your attention an active 
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packet group in New Jersey. The Cherryville 
Repeater Association has been in the forefront of 
packet operation starting with the original 
Vancouver boards and even starting a repeater 
interlink for voice discussion on packet protocol 
with other groups around the country. We are 
presently on the New Jersey 220 Repeater Network 
with AX.25 Ashby boards on 224.12, Mt. Kipp; 
224.52, Philadelphia; 220.54 Delaware Water Gap 
full time and can be accessed also from 223.78, 
Warrenville, NJ; 224.50, Newton, NJ; and 224.48 
MHz, Montclair, NJ. 


“We can also connect to any two-meter frequency or 
the telephone line for access to other networks. 


“A PBBS (packet bulletin board system) is 
available , and plans call for a main-frame PBBS 
and a teleport via OSCAR 10 soon. 


"We are even using packet for public service. In 
a rescue drill coinciding with SET (Simulated 
Emergency Test) weekend in October, relaying data 
on 80 victims to area hospitals from the disaster 
scene using portable packet terminals. 


“Our slogan sums it up: ‘Amateur Radio at its 
finest: community service through communication.’ 


“For more information call the club at (201)788- 
4080 or write: 

Cherryville Repeater Association, Inc. 

Box 308 

Quakertown, NJ 08868." 


Bill Ashby, K2TKN, is also a member of the 
Cherryville Repeater Association. He tells us 
that several stations on 220 MHz in New Jersey are 
using the V.2 protocol written by Doug Lockhart, 
VE7APU. While stations using V.2 can’t 
communicate with stations using AX.25, the 
experience of the group in New Jersey is that the 
two protocols can be used on the same frequency 
without any problems. 


Another interesting thing about this group is that 
they are using full-duplex repeaters shared with 
voice and RTTY users. 


From K2TKN and WB2NQV. 


TRAFFIC_ON SOUTHRET 


“There are 5 or 6 stations on SOUTHNET [Florida] 
that have been handling traffic since February. 
Messages are passed in radiogram format, although 
there has been some disagreement on what is the 
best message form, especially for messages that 
are handled only on packet. 


“The big problem here is gaining formal. 
recognition by an EC or STM as an NTS net. I'm 
not sure if the basis of the difficulty is that 
these officials don’t understand packet or the 
fact that there is no specific net time (QND) for 
these packet nets. Id like to hear from anyone 
who has gained or has suggestions for getting this 
designation. 


"The SOAPnet (SOUTHNET Amateur Packet traffic net) 
has outlets to the QFN Florida all-sections CW net 
(Cycle 4) and a couple of local ARES nets in the 
southern part of the state. 


“The big event of the SOAPnet was a traffic fair 
at a mall which used packet to relay the cache of 
traffic (about 40 messages) to a text editor. 
From there, one-quarter of the messages were 
cleared via packet channels alone; the balance was 
taken to QFN." 


From HowardGoldstein, N2WX. 


DNIX NOTE 


In Gateway issue 6, we noted that KA9Q has brought 
a UNIX system up on EASTNET. Those who sign onto 
the system (using the directions in Gateway) 
should type “info” when they see the "ka9q$" 
prompt. This will generate a brief introduction 
to what UNIX is all about and some instructions on 
how to do a few simple things such as send and 
receive mail. 


Via KA9Q. 


DIGIPEATER AS REMOTE TNC 


Ted Huf, K4NTA, operates the wide-area digipeater 
K4NTA-1 in Stuart, FL. The digipeater is located 
at Ted’s place of work, which happens to be a CATV 
company. The antenna is on the main CATV 
receiving tower at 300%, and it is fed with 7/8" 
hardline. The TNC is a TAPR Beta board, and the 
radio is a GE Master. All of this is not too 
unusual, but Ted also uses the TNC by remote 
control from his home. The TNC is connected to a 
dumb terminal in Ted’s shack via two 4800-bit/s 
CATV RF modems made for data communications on 
cable systems. The remote control has worked out 
very well, and since there are not many mountains 
in Florida, Ted has one of the best sites in his 
area . 


Ted reports further: “We now have wide-area- 
coverage digipeaters in Jacksonville, Melbourne, 
Stuart and West Palm Beach, Florida. W1BEL’s home 
station provides the link into the Tampa area on 
the west coast of Florida. Digipeaters are 
planned for Okeechobee, Miami, Orlando, Tampa Lake 
Wales and Ocala. There are now two PBBS stations 
on the air: K4NTA in Stuart and WD4LHF in West 
Palm Beach. Connections are routinely made with 
all areas that have packet activity. I estimate 
that there are around 100 stations on in Florida 
now. We are planning such things as PBBS linking 
for message exchange and would like to hear from 
others working on this.” 


Prom K4NTA. 


COORDINATION IN MINNESOTA 


The Minnesota Repeater Council, at their October 
27 meeting, voted to set aside 145.0 MHz to 145.1 
MHz exlusively for single-channel digital 
communications. This includes single-channel 
repeaters being used for packet radio. The 
allocation is divided into five 20-kHz channels, 
with the first channel centered on 145.01 MHz. 


From WOTH 


TELEPORT REWS 


As a first phase of the new AMSAT/ARRL Teleport 
STA, a unique packet-radio test was carried out on 
October 28. An automatic packet-radio bulletin 
board system (PBBS), operated by Tom Clark 
(W3IWI), was placed in experimental operation on 
the AMSAT-OSCAR-10 satellite. The W3IWI PBBS was 
successfully used by several amateurs across the 
U.S. and Canada. Earlier this year, successful 
PBBS tests through the same satellite had involved 
gateway links to existing terrestrial PBBSs in 
California. 


The following stations participated in the test 
and successfully logged onto the W3IWI PBBS: 


Randy Smith, VEIPAC/VE6, Medley, Alberta; 
Wes Morris, K7PYK, Scottsdale, AZ; 
Mac Jordan, W4DAQ, Demopolis, AL; 
Bob Diersing, N5AHD, Corpus Christi, TX. 


A number of other stations were monitoring and 
reported good copy. 


Both VELPAC and K7PYK sent and received several 
messages and files during their connections with 
the PBBS. K7PYK maintained contact for about an 
hour and managed to acquire about 50 kbytes of 
documentation from W3IWI. W3IWI and VEIPAC tested 
full-duplex PBBS operation through the satellite 
and achieved sustained data throughput of about 1 
Kbit/s, despite the 0.25-second round-trip 
propagation time to the satellite. 


The packet-radio hardware used at W3IWI is 
normally used as a local area PBBS, serving the 
Baltimore-Washington network. The PBBS uses a 
Xerox 820 computer wit8 software by Hank Oredson, 
WORLI. The terminal-node controller (TNC) used is 
a TAPR beta-test model. All tests were conducted 
at 1200 bit/s, 1000-Hz shift AFSK. 


Both N5AHD and W3IWI are among the 24 stations 
authorized by STA to operate unattended, automatic 
teleport stations. 


Packet operation on AMSAT-OSCAR~10 uses a downlink 
near 145.835 MHz, about 5 kHz up from the nominal 
AMICON digital network frequency of 145.830. 
(Operation was moved up to avoid sensitivity 
degradation experienced near the edge of the 
satellite passband. For packet radio, every dB 
counts.) 


Fron W3IWI 


AUTOMATIC MESSAGE FORWARDING 


Don Haney, KAIT is working on a PBBS devoted to 
NTS-type message handling, and he hopes to have 


the system up by December. Don is looking for 
other stations in New England that are interested 
in working on automatic FBBS-to-PBBS message 
forwarding. This type of store-and-forward 
operation will soon become very important to the 
growth of amateur packet radio. Interested 
parties should contact 


Don Haney 
Rd 1 Box 237 
Harvard, MA 0145]. 


Prom KAIT 


FLORIDA PACKET CENSUS. 


Howard Goldstein, N2WX, has compiled a list of 
stations active on packet radio in Florida. He 
lists 74 individual operators with a total of 77 
stations on the air. Five of the stations are 
wide-coverage digipeaters, and three stations are 
in bullet in-board service. 


Via DR NET 


TEXAS PACKET ACTIVITY 


David Cheek, WA5MWD, from the Dallas, TX area, 
sends along the following: 


“I’ve been on packet since August, 1983, first 
with a Vancouver TNC and now with a TAPR board. 
My main interest is in developing message handling 
systems for emergency service uses. This makes 
linking, high-level message relay, portable 
operations, and meteor scatter the specific areas 
that I expect to work in. The Texas VHF-FM 
Society appointed me to chair a group that will 
decide what frequencies should be used for packet 
radio in Texas.” 


Via DR NET 


ARRL PACKET ACTIVITY 


While Gateway has been concerned with reporting on 
packet-radio activity throughout the world, we 
have not provided an overview of packet activity 
in our own area, central Connecticut. In fact, 
the W1AW-4 packet bulletin board system (PBBS) and 
the WI1AW-5 digipeater are at the center of a 
growing packet community in Connecticut and 
southern Massachusetts. 


The Wl1AW-4 PBBS is located at ARRL Headquarters. 
The PBBS software was written by Jon Bloom, KE3Z, 
to run on a Xerox &20 computer connected to a TAPR 
TNC. The TNC that is currently being used is a 
TAPR beta-test model belonging to Paul Rinaldo, 
W4KI. RF is provided by an old Genave Z-meter 
rig. Because the W1AW bulletins and code practice 
are transmitted only a few hundred feet from the 
PBBS antenna, the PBBS does experience some 
reception problems during WIAW operating hours. 
There have been 300 messages left on the PBBS 
during its six months of sporadic operation. 


The W1AW-5 digipeater is located at the home of 
Dave Sumner, Ki1ZZ, General Manager of the ARRL. 
Originally, the digipeater used a VADCG TNC 
(running AX.25 protocol) and a VHF Engineering 
repeater. Due to repeated, mysterious failures of 


this system, it has been replaced by an AEA PKT-1 
TNC and a Heathkit 2-meter transceiver. Dave has 
put the WlAW-5 antenna on his 125-foot tower, and 
the repeater can be accessed reliably from 
throughout central Connect icut and south-central 
Massachusetts. 


When WIAW-5 is operating, stations in Connecticut 
can use several digipeaters in Massachusetts to 
connect with stations in the Boston-area packet 
network. Proposed digipeaters in eastern New York 
would connect WIAW-5 to New Jersey, the southern 
portion of EASTNET, and beyond. 


WIAW is one of the stations authorized by STA to 
operate as an unattended, automatic teleport 
stat ion. The RF hardware for satellite operation 
has been installed at the WIAW laboratory station, 
and teleport experiments will be started soon. 


We would like to thank Advanced Electronic 
Applications for donating a Z-meter antenna for 
W1AW-5 and Mirage for donating an amplifier for 
the digipeater. 


From K8KA 


ERROR IN.GATEWAY ISSUE & 


In the abstract of “RF Modems” by Hatchett and 
Howell, we mentioned a block diagram and schematic 
for a 1.5-kbit/s RF modem. In fact, the design is 
for a 1.5-Mbit/s modem. That makes it a bit more 
interesting. 


Via K1HOP 


ACTIVITY IN UTAH 


Ron Todd, K3FR, ARRL Section Manager in Utah, 
reports that there is some packet-radio activity 
in the in and around Utah’s Salt Lake valley. 
There are already 3 or 4 stations on the air, and 
others under construction. If the proper 
digipeater sites can be located, Utah could become 
an important link between the Pike’s Peak area 
(covered by the Rocky Mountain Packet Radio 
Association) and stations in the Pacific 
northwest. Because of this, Ron is particularly 
interested in high-level linking. 


via K3FR 


AMSAT MEETING 


AMSAT is holding its Second Annual Amateur Radio 
Satellite Symposium on November 10, in Los 
Angeles, CA. Of interest to Gateway readers will 
be “Computers and the Satellites,” presented by 
Bob Diersing (N5AHD) and "PACSAT Forum” with 
Harold Price (NK6K), Wally Lindstruth (WA6JPR), 
Rick Fleeter (WA8VGK), and Phil Karn (KA9Q). The 
next issue of Gateway_ will report on these 
meetings. 


DIGITAL COMMITTEE MEETING 


The ARRL Ad Hoc Committee on Amateur Radio Digital 
Communications will meet in conjunction with the 
AMSAT Symposium on November 10, At this meeting, 
groups will report on the progress made toward 


implementation of level-3 protocols, the state of 
development of high-speed modems, and availability 
of HDLC piggyback boards for the Xerox 820. 
Rumour has it that a 9.6 Kbit/s FSK modem for 220 
MHz, designed by Steve Goode, K9TD, will be 
demonstrated. 


DATAGRAMS AND VIRTUAL.CIRCUITS 


If you would like to learn more about the various 
approaches to packet networking, and two of the 
approaches to it being considered by amateur 
packet groups, you might be interested in 
Distributed Systems -- Architecture and 
Implementation, Lampson, Paul and Siegert, 
editors, Springer Verlag, 1981. Of particular 
interest is section 6.6 which discusses, in some 
detail, datagrams and virtual circuits. 


From KA9Q. 


REPRODUCTION OF GATEWAY MATERIAL 


Material may be exerpted from Gateway without 
prior permission, provided that the original 
contributor is credited and Gateway is identified 
as the source. 


Gateway: The ARRL 

Packet Radio Newsletter 
Aner ican Radio Relay League 
225 Main St. 

Newington, CT 06111 


Gateway: The ARRL Packet Radio Newsletter is 
published by the 


American Radio Relay League 
225 Main Street 
Newington, CT 06111 


Jeffrey W. Ward, K8KA 
Editor 


Larry E. Price, W4RA 
President 


David Sumner, K12Z 
Genera 1 Manager 


Subscriptions are available to ARRL members and 
nonmembers, at the following rates: 


For 25 issues of Gateway: 

In the U.S. 
ARRL Member $6 .OO 
Nonmember $9 .OO 

In U.S., Canada, and Mexico by First Class Mail 
ARRL Member $11.00 
Nonmember $14.00 

Elsewhere by Airmail 
ARRL Member $14.00 
Nonmember $17.00. 


Prices are subject to change without notice. 
Remittance must be in U.S. funds, and checks must 
be drawn on a bank in the U.S. 


Nonprofit Organization 
U.S. Postage 

PAID 

Hartford, Conn. 
Permit No. 2929 


Gateway 


The ARRL Packet-Radio Newsletter 


ARRL AND PACKET RADIO 


As mentioned in the last issue of Gateway, the 
ARRL Board of Directors, at its recent meeting, 
took several actions that affect packet radio. 
(See Board Minutes 11, 30, 36-38, 70, 98-99 in 
December, 1984 QST.) Deserving special attent ion 
are Minutes 98 and 99: 


“98) «. it was unanimously VOTED that the Ad Hoc 
Committee on Amateur Radio Digital Communications, 
packet radio clubs, and packet radio experimenters 
are commended for their work to date, and in 
particular, for their reaching agreement on the 
AX.25 link-layer protocol. 


"99)... it was unanimously VOTED that the 
Proposal for Packet-Radio Development Program...be 
adopted ." 


These two Board actions recognize that packet 
radio has come a long way in a short time, and 
that it still has a long way to go. 


The “Proposal for Packet-Radio Development 
Program” mentioned in Minute 99 is a document 
authored by Paul Rinaldo, W4RI, that details 
recent growth in packet radio, the goals of 
packet-radio experimenters, and actions that the 
ARRL might take to assist packet-radio 
deve lopment. While it does not attempt to allocate 
funds or personnel to packet-radio, it ends with 
the following list of recommended actions: 


1. Board Actions 
a. Approve the AX.25 link-layer protocol. 
b. Support the Digital Committee. 


c. Approve ARRL laboratory support of packet 
radio. 


d. Approve San Francisco as the site for the 
Fourth ARRL Amateur Radio Computer 
Networking Conference. 


e. Encourage more Board Members to get on the 
air with packet. 


2. Headquarters Act ions 


a. Publish the AX.25 Amateur Packet-Radio 
Link-Layer_Protocol_ document. 


b. Develop a nontechnical flyer on packet 
radio for answering mail inquiries and as a 
handout for field use. 


c. Publish more packet-radio articles in QST, 
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and do club profiles on clubs contributing 
to packet radio. 


d. Work with the Connecticut Section 
Leadership Officials to develop a 
demonstration “model section” with a 
variety of packet-radio services. 


e. Continue ARRL lab technical support of 
packet-radio experimenters, particularly in 
preparing descriptions of designs for 
League publicat ions. 


f. Configure W1AW for packet-radio teleport 
operation and conduct tests with other 
teleports under a special temporary 
authority granted by the FCC. 


g. Produce a slide show or video tape on 
packet radio. 


3. Ad Hoc Committee Actions 


a. Coord inat e and support exper iment s lead ing 
to an early agreement on network and 
transport protocols. 


b. Develop a message protocol capable of 
supporting Amateur Radio emergency 
communications, NTS traffic, inter-PBBS 
exchanges, and other electronic-mail 
applications. 


c. Work towards developing standards for other 
protocol layers. 


d. Encourage development of higher-speed 
packet-radio systems. 


e. Investigate ways of reducing the cost of 
packet radio to amateurs. 


Obviously, not all of these items will be acted on 
immediately, and some may give way to more 
fruitful or critical projects. However, this 
program does indicate that the ARRL Board 
recognizes the potential of packet radio to 
improve Amateur Radio, making it a more 
interesting, advanced hobby and a more effective 
tool for public service. 


ED 


ARRL DIGITAL COMMITTEE MEETING 


The ARRL Ad Hoc Committee on Amateur Radio Digital 
Communication held a meeting in Los Angeles, on 
November 11. Highlights from the Meeting Minutes 
follow. 


The ARRL VHF/UHF Advisory Committee (VUAC), and 
the Southern California Repeater and Remote Base 
Association (SCRRBA) have reached an agreement on 
a national band plan for the 23~cm band. The 
Digital Committee reaffirmed its stand that the 
digital communications frequencies provided in the 
now band plan would be adequate for the 
development of packet radio. 


Tucson Amateur Packet Radio (TAPR) has completed 
prototypes of the six-chip packet I/O add-on for 
the Xerox 820 computer. These add-ons should be 
available from TAPR at the end of November. 
[Please wait for an official TAPR announcement 
before attempting to order this kit. -- Ed] 


The Committee discussed how best to present 
information on packet-radio repeaters in the ARRL 
Repeater Directory. The committee will recommend 
that digital repeaters be listed in the main body 
of the directory as well as in a special section 
devoted to digital repeaters. This would give 
visibility to digital operations, perhaps alerting 
amateurs to digital activity in their area. The 
Committee also recommended that secondary-stat ion 
identifiers (SSIDs) be added to the call signs of 
packet repeaters listed. It was further suggested 
that the Repeater Directory include a list of 
frequencies used for packet operation, and that a 
system be developed for identifying stations 
providing special services (such as gateways, 
teleports and bulletin boards). 


Following up on an earlier discussion, the 
Committee agreed to encourage TNC developers to 
cooperate in standardizing the interface to user 
terminals. Doug Lockhart, VE7APU, will be the 
Committee’s clearing house for this matter. Such 
a standard interface will be similar to that 
presented in CCITT Recommendations X.3 and X.28 
and will make it much easier for users to operate 
TNCs made by different manufacturers. 


The Digital Committee discussed several other 
matters, including transceiver turnaround delay, 
message forwarding, and the problems of mountain- 
top packet installations. As various projects 
undertaken by the Committee mature, they will be 
addressed in Gateway. 


Via W4RI 


AUTOMATIC CONTROL 


It was reported in the last issue of Gateway that 
the ARRL was preparing a pet it ion for rule making 
asking the FCC to allow automatic control of 
digital communications above 30 MHz. Excerpts 
from the petition, filed on November 14, follow. 


“The American Radio Relay League...requests that 
the Commission. ..permit automatic control of 
digital communications on all amateur frequencies 
above 30 MHz, provided that certain safeguards are 
incorporated in the amateur station as control 
functions... 


“There are now...provisions for use of digital 
communications in the Amateur Radio 
Service. ..These types of digital communications, 
especially since the advent of request-repeat 
radioteleprinter systems such as AMTOR, can be 
done with a great deal of reliability without a 
control operator present. Amateur stations, 


utilizing present microprocessor and computer 
technology now routinely present at amateur 
stations, can automatically transmit and receive 
digital communications, verify receipt of 
messages, and respond when inquired of. The use 
of Computer Based Message Systems is a new aspect 
of amateur communications which should be 
encouraged, consistent with establishment of 
standards for good amateur operating practice. 
digital communications has progressed to the point 
that automatic control of digital communications 
is both feasible and necessary to facititate 
further development of such experimentation. 


“automat ic operation would be subject to the 
inclusion of adequate circuitry to assure (1) the 
detection of transmitter malfunction and, upon 
detect ion thereof, automatic transmitter shutoff; 
(2) the capacity to prevent transmission of 
improper message traffic, such as business 
communications; (3) means to prevent transmission 
while the channel is occupied; and (4) compliance 
with all other applicable technical and 
operational standards for amateur radio stations. 


“Of course, the authority to utilize automatic 
control of digital communication would not alter 
the primary responsibility of the station licensee 
for proper station operation. The League Board of 
Directors has adopted interim standards for good 
amateur practice for digital communications, and 
specifically for establishment and operation of 
computer-based message systemS ee [See October, 
1984 QST, “Operating News”--Ed.] The promulgation 
of such guidelines will assist in assuring 
responsible use of the automatic control sought by 
this Petition. 


“The Commission has twice recently emphasized its 
objective of encouraging new technologies’ in the 
Amateur Service, balanced against assuring 
enforcement capability. In this context, no 
enforcement problems are created by the proposed 
rule change. Yet, the added authority would 
greatly facilitate and encourage amateur digital 
experimentat ion and increase communication 
effectiveness. 


“Given the heavy use of high frequencies [below 30 
MHz], it is believed that manual control for 
digital communications is more appropriate [on 
those frequenc ies ]." 


Remember, this petition for rule making is just 
the first step in the long process of requesting 
and gaining a rules change. Gateway will keep you 
informed on the progress of this pet it ion. 


ST. LOUIS DIGIPEATER 


On Saturday, October 10, St. Louis Area Packet 
Radio (SLAPR) installed its first permanent 
dig ipeater , KOPFX-1. The digipeater is located in 
downtown St. Louis on the TV channel 30 tower, at 
the 400-ft level. The antenna (a Ringo Ranger) is 
fed with 400 feet of hardline. The TNC is a TAPR 
beta board that has been upgraded to perform like 
a TAPR kit TNC, The RF end of the installation is 
an IC-22S running 9 watts. Several St. Louis-area 
amateurs donated the equipment and packaged it in 
a cabinet purchased by SLAPR. Wiring and 
installation of the loaned equipment was 
undertaken by Mel Whitten, K@PFX, 


Although the feedline is long and the rig is not 
runn ing high power, signal reports from the first 
evening of operation were promising. Packet 
stations as far away as Greenville, Illinois were 
able to copy. This is a 40-mile path -- not bad 
for the flatlands of the midwest! 


From WB9FLW 


VANCOUVERDIGIPEATER 


The Vancouver Amateur Digital Communications Group 
(VADCG), one of the groups that pioneered amateur 
packet radio, has installed a 145.65-MHz wide- 
coverage digipeater on Burnaby Mountain. The 
equipment is a VADCG TNC with repeater and beacon 
software, an IC-22S transceiver, and a multi- 
element beam aimed south (toward the U.S.). 
Coverage is good into Bellingham, Washington, and 
reports have been received from as far south as 
Edmonds, Washington. Local coverage includes 
greater-Vancouver and the Fraser Valley. There 
are about a dozen Canadian stations active on the 
dig ipeater, and there are several active stations 
in Be 11 ingham. Others are still in the process of 
bringing up TNC boards and modifying VADCG TNCs to 
support the V.2 protocol. Many stations have 
Xerox 820 boards providing network services, and 
WA7PIX has had his Xenix system on line. Packet 
operators visiting the Vancouver area are 
encouraged to use the machine. 


From VE7DPM 


SEATTLE, WA PACKET CLUB 


A packet-radio club called the Northwest Amateur 
Packet Radio Association (NAPRA) was formed in 
Seattle, WA on November 13. The officers of the 
club are Dennis Goodwin, KB7D2Z; John Gates, N7BTI; 
John Hays, KD7UW; Bud Churchward, WB7FHC; and Tom 
Hogan, W B7DCH. The group has about 30 members. 
The Seattle area supports two hilltop digipeaters 
(on 147.6 MHz and 224.56 MHz) and two packet radio 
bulletin board systems (PBBSs), with coverage from 
Olympia to Bellingham. Club meetings will be on 
the second Saturday of each month, and the club 
holds a voice net on 145.33, Thursday from 2100 to 
2200 local time. Plans are to link the Seattle 
area to British Columbia, eastern Washington, and 
Port land, Oregon. 


Via N7TBI 


ACTIVITY IN VIRGINIA 


We received the following letter from Peter 
Lascell, W4WwQ. 


“Packet is coming to central and southwest 
Virginia after WD40LV recently moved into the 
area. Rick has presented a couple of club 
programs in the area, and the ball is rolling. 


“About a half-dozen stations are actively 
assembling equipment in the Roanoke, VA area, and 
there are plans to install a 145.01~MHz digipeater 
atop Poor Mountain, near Roanoke. Poor Mt. is 
about 4,000 ft high, and is the current site of 
the WB4Q0J voice repeater. The RF equipment is 
ready, and we are just waiting for the GLB PK-1 to 
make it fly. The earliest date for complete 


installation is the Thanksgiving Day weekend. 
This repeater should provide coverage down to the 
Florence, SC packet repeater as well as up the 
Shenandoah valley to EASTNET near Washington, D.C. 
Users in Greensboro, NC, Blacksburg, VA, and 
Lynchburg, VA,will have easy access to the Poor 
Mountain digipeater. More distant stations, from 
areas like Raleigh-Durham and southeastern West 
Virginia should be able to access the machine if 
they have good outdoor antennas. 


“There are at least five stations in Lynchburg, VA 
with TNCs in their shacks, although some of the 
TNCs are still in kit form. There are basically 
two levels of computer interest here -- those with 
Vic 20 or C 64 computers who still play games when 
the propagation is bad, and the CP/M crowd with 
Big Board and Xerox 820 computers. 


“As activity builds, we will evaluate the merits 
of another repeater on the east side of the Blue 
Ridge. The primary intent of such a machine would 
be to link the western part of the Commonwealth 
with Richmond, providing access to the State 
Office of Emergency Services. (We are very much 
public service oriented.)” 


From W4WwQ 


NEWS FBOM GLB 


From the Packet Software Approach Newsletter, we 
hear that GLB electronics expects to have a "PK2" 


in a few months. The use of a Zilog Serial I/O 
(SIO) chip should allow the PK2 to run much faster 
than the current GLB PKI, which uses no SIO. 


Via W40CH 


PACKET IN ONTARIO 


The Hamilton Amateur Packet Network (HAPN) now has 
two digipeaters on the air: VE3PKO on 145.710 MHz, 
and VE3PKT on 145.650 MHz. One of these machines 
is in Toronto, and one of them is just south of 
Toronto. Most of the stations on HAPN are using 
Vancouver TNCs modified to run AX.25 protocol. 
Stewart Beal, VE3MWM, even has AX.25 and the 
Vancouver protocol running on his VADCG TNC. If 
you are in the area, HAPN runs a voice net on two 
meters~-147.735/147.135 MHz, Monday night. 


via W4UCH 


PACKET READING 


Looking for something to read about packet- 
switched data networks? The following list came 
to us via Compuserve’s HAMNET: 


Communications Networks for Computers, by Davies 
and Barber. 


Computer Networks and Their Protocols, by Davies, 
Barber, Pricand Solomonides. 


Data Communications, a User’s Guide, by Kenneth 
Sherman. 


Packet Switching, by Roy Rosner. 


Telecommunications_ and the Computer, by James 


Martin. 
Telecommunications System Engineering, by Freeman. 


From W2JUP 


WHERE TO FIND THEM 


You probably won’t find these books in your local 
book store or even at your public library. The 
best place to find books and magazines mentioned 
in Gateway is at the library or book store of a 
college of engineering. There is usually some way 
for people who are not students or staff members 
to check out books -- just don't take "no" for an 
answer . 


From K8KA 
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AUTOMATIC FORWARDING 


From the user’s point of view, the most 
interesting packet-radio development of the past 
few weeks is the implementation, by Hank Oredson, 
WO@RLI, of automat ic message forwarding. Hank is 
the author of The MailBox, a packet-radio 
bulletin-board system (PBBS) that runs on the 
Xerox 829 computer. The newest feature of The 
MailBox is automatic store-and-forward message 
hand 1 ing, which allows a message left on a 
MailBox to be passed from one MailBox to another 
until it reaches its intended recipient. our 
experience with the system, between Hank, in 
Boston, and WLAW-4 in Newington, CT, has been 
f avorab le. 


Hank says, “The distributed message store-and- 
forward system is growing Iverynrapidty. h e 
Boston area, KIBC, WORLI, WB20SZ, and KAIT are all 
using auto-forwarding. In Arizona, K7PYK is 
available, linked to W@RLI via HF. Other EASTNET 
MailBoxes now on the air, or soon to be on the 
air, include W3IWI and KS3Q in the Washington, 
D.C. area, WB2MNF in New Jersey, and WIAW-4 in 
New ing ton. At least nine other stations should be 
coming up in the future. The network, both real- 
time and store-and-forward, is growing fast.” 


While the easiest way to get into the store-and- 
forward network is to use Hank’s MailBox software, 
experience at WIAW has shown that other PBBS 
software can be modified to work with the MailBox. 
Hank would like to get in touch with anyone 
working on store-and-forward techniques. [See 
“The MailBox" later in this issue of Gateway for 
more information on Hank’s software. -- Ed.] 


Ed. 


TELECONFERENCE RADIO NET 


Packet radio was the topic of the December 2nd 
Teleconference Radio Net (TRN), which featured 
Lyle Johnson, WA7GXD, and Harold Price, NK6K. 
This net, heard on many repeaters throughout North 
America, should generate a lot of new interest in 
packet radio. 


Lyle and Harold addressed the basics of packet 
radio, the state of packet radio, packet-satellite 
projects, and the future of packet radio. 
Questions from the audience showed increasing 
awareness of and interest in packet radio. 


Congratulations to Lyle and Harold for presenting 
a clear and interesting introduction and overview 
of packet radio. Congratulations also to the 
Midway Amateur Radio Club for its first TRN; the 


net was well controlled, and the audio was 
beautiful. 


Ed. 


PACKET RADIO VIDEO TAPES 


The Central Iowa Technical Society (CITS) was 
privileged to host the first ARRL Iowa Section 
Technical Seminar on September 22nd, 1984. The 
guest speakers at that convention were Lyle 
Johnson, President of Tucson Amateur Packet Radio 
(TAPR), and Jeff Ward, K8KA, ARRL laboratory 
computer engineer and editor of Gateway. The 
weekend before the Seminar, Lyle and Jeff had 
attended a meeting of the ARRL Ad Hoc Committee on 
Amateur Radio Digital Communications, and they 
were well prepared to present the latest ideas and 
agreements relating to packet-radio networking. 


CITS took the opportunity to video tape Lyle’s 
discussion of the concepts of networking and, with 
the addition of a segment about the lowa 
networking project, they have produced a video 
tape called “Amateur Packet-Radio Networking.” 


Lyle’s d iscuss ion includes a brief review of 
packet-radio basics, a discussion of the use and 
limits of level-2 digipeaters, a comparative 
review of datagrams and virtual circuits, and 
speculation on potential of packet-radio 
networking to provide continuous, highly reliable, 
error-free inter-city linking. 


CITS has followed Lyle’s discussion with a 
description of their own networking project, which 
includes a “link-management unit” (LMU) based on 
surplus Televideo 866 microcomputer boards and 
22G-MHz RF modems. This description is in the 
form of a panel discussion including John Maurer, 
NAGS, Dave Huffman, KAQ@DNB, and Ralph Wallio, 
WORPK . 


The video tape is ready for distribution and may 
be ordered in either VHS or BETA format. Please 
send $25 (in check made out to Central Iowa 
Technical Society) to: 


Allen Johnson, WB@OEU 
cio CONTROLTRACK 

2212 Ingersoll Avenue 
Des Moines, IA 59312. 


If you are just getting interested in packet 
radio, perhaps as a result of the December 2 TRN, 
CITS’s first video production, “Introduction to 
Packet Radio" is still available through the same 
address, for the same cost. Funds remaining after 
CITS’s overhead is paid will be used to continue 


development of packet-radio networking. 


Prom WORPK 


BAGS IV ITY 


The following summary of the activities of the 
Radio Amateur Telecommunication6 Society (RATS) 
was sent to us by Gordon Beattie, N2DSY. 


“The new repeater is up and running in a revised 
form. It sports an Ashby TNC, a Bell 2¢2T modem, 
a dual-function watchdog timer, and an ICOM IC- 
25A. The new site, in Little Falls, New Jersey, 
improves coverage of the New York metro area. The 
package is now housed in an all-weather cabinet 
provided by Mike Friedman, WB2WNX. This will 
eliminate operational problem6 encountered during 
each of the past winters. The dual-t imer c ircuit 
provides a timeout for the transmitter, and a 
reset timer in case the repeater “goes to sleep.” 
This circuit has already paid for itself in saved 
gasoline. 


“Our bulletin board will be on the air in the next 
few weeks, providing access to news and reference 
data for both advanced and beginning packeteers. 
We will be running a modified RBBS on a Big Board 
computer with 759% kbytes of disk storage. Weare 
also investigating a link to the New Jersey 
Institute of Technology’s Electronic Information 
Exchange System. This system provide6 informat ion 
on many subjects, including computers, sociology, 
language, mathemat ics and leisure. This system is 
also host to the Digital Radio Net (DR NET) group 
that is coordinating packet development efforts 
here in North America. 


“We’ve also been busy in the protocol development 
area. We have a draft recommendation for an 
international numbering plan and another in the 
works for a national numbering plan. The 
international plan closely follows the CCITT 
x.121. This is a particularly interesting 
recommendation because it allows for data users to 
call telephone and telex users. An amateur 
implementation of this addressing scheme would 
simplify connections between amateur and 
commercial net works. This would greatly enhance 
amateur network operations, provided that proper 
control and third-party traffic regulations could 
be observed. 


“The national plan to be proposed will be based on 
the North American Numbering Plan used in the 
telephone network. Our goal was to develop an 
easily determined numbering scheme for use in the 
amateur network, and we couldn’t think of a more 
reliable directory service than the one maintained 
by AT&T and others!” 


[Numbering will be necessary in an amateur packet 
network because amateur call signs are not 
geographically specific enough to be used in 
determining packet routing. Several numbering 
schemes are under consideration. -- Ed.] 


For more information about RATS, contact: 
RATS 
c/o J. Gordon Beattie, Jr., N2DSY 
266 North Vivyen St. 
Bergenf ield, NJ 97621. 


From N2DSY 


EASTNET NEWS 


Tom Clark, W3IWI, reports on the central division 
of the East Coast Packet Network, EASTNET: 


“On sunday, November 25, about a dozen active 
packeteers from Maryland (Balt imore and Washington 
D.C.), southern New Jersey (Camden) and 
southeastern Pennsylvania (Harrisburg) met at a 
rest stop on Interstate 95 near the MD/DE border 
(approximately equidistant from the three centers) 
for the purpose of coordinating EASTNET 
activities. 


“One of the major topics at the meeting was the 
availability of digipeaters. The critical “hub” 
of intercity communication6 is the WB4APR-6 
digipeater at Elk Neck, MD (the head of Chesapeake 
Bay). This remote system has been a bit ill for 
the past few weeks, but is now back on the air. 
Reports on local digipeaters were presented. 
W2FPY-7 is now operational in Hopewell, NJ, 
serving as a relay northward in NJ. A Camden, NJ 
location has been picked to serve the Philadelphia 
area better. In Harrisburg, PA, WA3KXG is now 
operational. In the Baltimore/Washington D.C. 
area, WB4JFI-5 and W3VD-5 are operational. W3GXT- 
5 is on experimentally in Baltimore, and K3JYD has 
plans for a southern MD digipeater that could link 
to Richmond, VA. 


“The next topic of discussion was packet bulletin- 
board systems (PBBS). WB2MNF (NJ/Philadelphia 
area) and W3IWI (Baltimore/Washington area) are 
running the latest W@RLI MailBox software with 
automatic inter-PBBS message forwarding. In the 
Baltimore/Washington area, KS3Q provides backup to 
the W3IWI PBBS. WB4APR-5 serves as a gateway to 
10 MHz, and occasionally W3IWI provide6 a teleport 
gateway through the A0-1@ satellite. After 
sorting out PBBS user lists, there was 
considerable discussion of efficient use of 
current linking capability. 


“It is becoming obvious that 145.01 MHz is getting 
clogged in the major metropolitan areas. We 
decided to recommend that users QSY to 145.03 MHz 
or 145.05 MHz whenever they have simplex paths 
available. It was also decided that the PBBSs 
should continue to operate on the 145.01 “primary” 
frequency until such time as the PRBS software 
supports QSY on request. 


“The topic of beacon messages and CW IDs provoked 
a good discussion. Since the FCC has dropped the 
CW ID requirement for users, it was decided that 
we should recommend that al 1 stations cease CW ID 
as soon as possible. There was some discussion 
(and a move to review the FCC rules) to see if 
dedicated digipeaters really have to have CW IDs 
-- after all, they identify themselves every time 
they repeat a packet. It was also agreed that all 
user beacons be discouraged except for PBBSs and 
Gateways that need to send “Mail for:...” beacon 
messages periodically. It was further agreed that 
there is no need for digipeaters to send beacon 
messages at all. 


“A lot of hope was expressed that we would soon 
begin implementing 22Q@-MHz links for intercity 
communications. The long-haul links could profit 
from not having to contend with local-area users. 


“All in all, it was a great way to spend a sunny 
Sunday afternoon. All attendees agreed that it 


was well worth the 5¢- to 1$%-mile round trip to 
get there.” 


Prom W3IWI 


CONTINUING TELEPORT EXPERIMENTS 


Experiments continued in November under the 
AMSAT/ARRL teleport STA. 


ZLIAOX was linked to WB5EKU via an OSCAR-10 
teleport station using the following links: 
ZLIAOX, Ian Ashley, Auckland, New Zealand, OSCAR 
1%, Mode B; NK6K, Harold Price, Redondo Beach, CA, 
OSCAR 196, Mode B; NK6K-2, Redondo Beach, CA, 
145.36-MHz FM; WA60ZJ, Jim Johnson, Rolling Hills, 
CA, 145.36 MHz-FM; WB5EKU, Don Jacob, San Fernando 
Valley, CA, 145.36-MHz FM. 


WH6AMX, Rick Dittmer, was linked (I’m resisting 
the urge to say he was teleported, which sounds 
too much like Scotty beamed him up.> via NK6K to 
the WB6YMH-2 remote CP/M system run by Skip Hansen 
on Palos Verdes, a local California hilltop. 
Several kbytes of data were moved under computer 
control from California to Honolulu. 


Refer to Fig. 238, page 19-23 of the 1985 ARRL 
Handbook for the Radio Amateur for a diagram of a 
similar linkup using the KA6M teleport station. 
The teleport STA permits experimentation with 
fully automated teleports, and the coming months 
will see the development of teleports as “hands 


off? as a standard digipeater. 


From RK6K 


WESTNETNEWS 


In more down-to-earth linking news, WESTNET has 
linked San Diego to San Francisco. For this 
winter, at least, WESTNET uses two audio hops to 
link Los Angeles to a point near Fresno. A key 
point in WESTNET is the WA6RWN station, a totally 
solar-powered mountain with interlinked 
“repeaters” on 59, 144, 226, and 44@ MHz. This 
station is used as the northmost audio link for 
packet-radio communications. Init ial testing 
succeeded in connecting northern and southern 
California digipeaters. This should allow access 
from the Mexican border to north of San Francisco. 
Extended testing, tuning, and aligning of the 
WA6RWN machine depleted its 4$¢ amp-hour batteries 
,» so regular linking of North and South awaits a 
few More sunny days. 


The audio paths will be replaced by digital links 
in the 229- and 12@@-MHz bands in the spring. A 
more complete description of the current system 
will be forthcoming. 


From NK6K 


NTS PACKET NETS 


We received the following from William Jochimsen, 
the Section Traffic Manager (STM) for the Southern 
Florida Section. Mr. Jochimsen is responding to 
Howard Goldstein, N2WX, who wanted to know how to 
gain formal NTS recognition of a packet traffic 
net. 


"I perceive no difficulties in recognizing a 
packet-radio net, provided monthly net reports are 
received, as with any other traffic net. As for 
the message format for packet radio, I have 
recommended the preamble be on the first line, the 
address and phone number on the second line 
(separated by commas), the text on following 
lines, and the signature on a separate line at the 
bottom. This format was used recently in a local 
‘emergency’ exercise and seemed to work fine.” 


So, if you want your message handling on packet 
radio to be recognized by NTS, simply send a 
monthly net report to your STM. It should be 
fairly easy to have your net report automatically 
generated and delivered. 


Ed. 


CIPBUS PACKET-USERS DIRECTORY 


The Central Illinois Packet Radio User Society 
(CIPRUS) has completed the first edition of its 
Packet User’s Directory, with 4% stations listed. 
Greg Smith, N9AGC, tells us that the second 
edition cannot be far behind, since the CIPRUS 
data base now contains 5§§ stations. The club was 
a bit surprised by the costs required to print and 
mail the directory, and asks that those who 
request the directory make at least a $5 donation. 
All funds go directly to CIPRUS to cover printing 
of the directory and to advance packet links in 
Illinois. The directory has three sections, an 
alphabetical listing of stations by call sign, a 
Zip code sorted listing of stations, and a 
description of each locality with frequencies, 
local-area nets, nets, clubs and other 
information. 


Congratulations to CIPRUS ! 


Via N9AGC 


LONG ISLAND PBBS 


There is a new packet bulletin board system on 
220.780 MHz, in Port Jefferson, NY, on Long 
Island. Norm Sternberg, W2JUP, is running a RTTY 
repeater on 223.189/223.789 MHz. The PBBS 
operates simplex on the output frequency. The 
access command is "<cr><lf£>W2JUP<cr><1f£>" for a 
C 64 computer running the “Mailbox 64” program. 
This system will alternate some evenings with an 
Apple II “Super Ratt" system, with access code 
"sW2JUP<cr><1f£>", The packet system uses an AKA 
PKT-1 TNC, and runs about 34 watts ERP at 330 feet 
above sea-level. [That’s quite a mountain for 
Long Island. -- Ed.] 


Via HAMNET 


WORLI MailBox SOFTWARE 


As mentioned several places in this issue of 
Gateway, Hank Oredson, W@RLI has written a 
versatile PBBS called "MailBox." Far from being a 
run-of-the-mill PBBS, Hank’s program has many 
innovative and useful features that make it 
outstanding. 


The program runs on the Xerox 82$ computer, with 
2 disk drives and a TAPR TNC. 


The bulletin-board section of MailBox stores 
messages, transmits broadcast packets telling who 
has messages waiting, and delivers your messages 
to you when you connect to the PBBS. The addition 
of automatic message forwarding, as mentioned 
earlier, makes this a powerful program. 

The MailBox also has a “gateway” or “bridge” 
feature which allows the Xerox to control two TNCs 
on different frequenc ies. For instance, stat ions 
on 2 meters can use the gateway to connect to 
stations on an HF band like 19 MHz. The gateway 
feature has been used to link stations from 
Arizona to Massachusetts. 


To get a copy of MailBox, send an 8" disk, with 
return postage, to 


Hank Oredson, WORLI 
19 N. Hill Rd. 
Westford, MA 01886. 


Ed. 
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ATTENTIONGLB DIGIPEATER USERS 


If you are using a GLB PKe-1 primarily as a 
digipeater, you should immediately get a software 
update from GLB. Software prior to Version 3.5 
will not digipeat multiple frames with multiple 
digipeaters. If a GLB PKe-l is specified as part 
of a multirepeater path, only the first frame in 
any transmission will be repeated. This can 
exponentially increase the traffic on a channel 
where a PK-1 is a wide-coverage digipeater. 


To get your software updated to Version 3.5, send 
a $10 deposit (or your current PROMs) to GLB. 
When you receive your new PROMS, send the old ones 
to GLB and you will get your deposit back. 


This is an important problem, and should not be 
ignored by GLB users. The GLB address is 

GLB Electronics 

1952 Clinton St. 

Buffalo, NY 14206. 


From GLB. 


MORE FROM GLB 


In Gateway. issue 8, we reported that GLB 
electronics, makers of the PK-l1 TNC, were at work 
on the PK-2. Ed Jackson, an engineer with GLB, 
was able to confirm that preliminary engineering 
work is being done on the PK-2, but that it is 
primarily a “commercial TNC." More important for 
the radio amateur is GLB’s development of the PK- 
R, an integrated VHF radio and TNC. On the RF end 
of the PK-R is a 25-watt crystal-controlled, 
highly stable FM rig. The packet equipment is a 
PK-1TNC. For repeater operation, you simply 
connect the PK-R to a 12-V supply and an antenna, 
hit the reset button and you’re on the air, For 
home-station use the rig has an RS-232C connector 
that goes to a terminal or computer. The PK-R is 
ready for type-acceptance tests, so look for it on 
the market before long. 


Mr. Jackson also reports that a 200-Hz shift 
modification for the PK-l is almost complete. 
This, along with an existing 300-bit/s 
modification will allow PK-1 users to join the 
growing number of HF packet users. 


Ed. 


TWO-METER BAND PLANNING 


In several metropolitan areas, the amount of 
packet-radio traffic has exceeded the capacity of 
a single 1200-baud channel. On the east coast, 
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the channel that is full is 145.01 MHz, and one of 
the most-asked questions is “what frequency do we 
go to next?“ This question has no simple answer. 


Ultimately, packet radio will move up to and above 
220 MHz. When intercity “backbone” links are 
running on 220 MHz, the congestion on 2 meters 
will be eased. However, even when the network 
backbone is in place and experienced packet 
operators are moving to higher transmission speeds 
on higher frequencies, local traffic and “entry- 
level” packet operation will be on 2 meters. 


So, the question remains: What frequency do we go 
to next? Some people on EASTNET have proposed a 
20-kHz channel spacing, using 145.010, 145.030, 
145.050, 145.070 and 145.090 MHz. Albert 
Hamilton, AGIF, Chairman of the New England 
Spectrum Management Committee points out that “Any 
rig produced in the last 6 years is perfectly 
capable of operating on a 15-kHz spacing without 
undue problems. While there are some real pieces 
of junk operating on 145.010 MHz now, that is no 
reason to give up sensible spacing.” Using a 15-= 
kHz spacing would provide six channels between 
145.000 and 145.100 MHz -- one more channel than 
could be provided with 20-kHz spacing. We may 
need this extra channel in a few years. 


If packet activity in your area is beginning to 
move away from 8 single 2=-meter frequency, 
consider the arguments for a 15-kHz spacing. If 
you have any comments on this topic, address them 
to Gateway and 


Albert W. Hamilton, AGIF 

Chairman 

New England Spectrum Management Committee 
54 Hathaway Ave. 

Beverly, MA 01915. 


Ed. 


RTTY-TO-PACKET GATEWAYS 


Albert Hamilton, AGIF, who made the above 
suggestions concerning band planning, is also 
interested in working on a RTTY-to-packet gateway. 
Ideally, such a gateway would operate in real- 
time, allowing the RTTY user and the packet user 
to have a proper contact without knowing what mode 
the other operator was using. An alternative to 
this scheme would be to have a bulletin-board 
system that could be accessed by both packet and 
RTTY stat ions. Since there are already many 
stations equipped for Baudot RTTY, packet-to-RTTY 
gateways could bring interested amateurs in 
contact with packet radio while increasing the 
utility of packet networks for traffic handling. 


If you have undertaken a packet-to-RTTY project, 
send the details to Mr. Hamilton and Gateway. 


From AGIF. 


PACKET IN. PENNSYLVANIA 


Gary Hoffmann, AK3P, sends us a summary of packet 
activity in central Pennsylvania. Gary got his 
TAPR TNC in June, and was the first station on the 
air in the Harrisburg, PA area. Shortly after 
that, Bob Warrington, WB3FQL, and Tim Shiogara, 
WB3EYB, were also in operation. Tim supplied a 
link to WB4APR near Balitmore, and the group 
gained access to EASTNET. 


In October, Gary installed a wide-coverage 
digipeater above Harrisburg in the building of the 
Central Pennsylvania Repeater Association. The 
digipeater, running under the call WA3KXG, is in 
operation 24 hours per day, on 145.01 MHz. From 
its 1400-foot elevation, WA3KXG provides a 
reliable link into Baltimore, Washington, and 
Virginia, via WB4APR and W3VD. A link into New 
Jersey has been established through WB3FYL and 
W2FPY. 


There are presently about 5 stations on packet in 
the Harrisburg area, all using TAPR TNCs. Gary 
hopes that activity will increase in the near 
future, with links established into Scranton, PA 
and New York state. 


Another item from Pennsylvania: Neil Sablatzky, 
WA2WIM, in Edinboro, PA (near Erie) is interested 
in becoming active on packet. His problem is that 
no one else in his area is interested. He would 
like to help link Northwest Pennsylvania with the 
eastern and southern parts of the state. He would 
also like to establish some contacts into the 
Buffalo, NY area. Neil would like to hear from 
anyone near Erie who is working on packet 
networking. He can be reached on the WB3USH 
repeater on 146.76 MHz, where he will be listening 
on packet when his TAPR TNC arrives. You can 
write him at: 

201 Granada Drive 

Edinboro, PA 16412. 


From KC2WZ and AK3P 


MIDWEST NETWORKING 


The packet-radio network that has grown up around 
central Iowa has finally reached the Iowa- 
Minnesota border. Lyle Monson, W@FQ, is active 
from Spirit Lake, IA. 


Lyle wants to know what frequencies are being used 
in southern Minnesota, and is looking for some 
active stations to hold schedules with. He will 
be able to connect to the rest of the Iowa packet 
network via WQ$ZVY, the wide-coverage digipeater in 
Guthr ie Center, IA. 


The Central Iowa Technical Society (CITS) is 
planning a 220-MHz intercity network. They are 
looking for a station around Mason City, IA to 
extend this backbone to the north. 


From WORPK. 


MT. BEACON DIGIPEATER 


The gaps in EASTNET are beginning to be filled in. 
The addition of the WB2KMY digipeater on Mt. 
Beacon, NY will help to tie both Boston, MA and 
Newington, CT into the southern portion of the 
network. 


The Mt. Beacon digipeater, on 145.01 MHz, is the 
first part of an ambitious project being 
undertaken jointly by the Mt. Beacon Amateur Radio 
Club and the Putnam Emergency Amateur Repeater 
League (PEARL). When the project is complete, 
there will be two complementary digipeaters in the 
mountains around Poughkeepsie, NY. One of the 
machines will be on Mt. Beacon, a site that has 
good coverage to the west. The other will be on 
Mt. Ninham, with a clear path to the east. Tht 
two clubs will be working together to minimize 
interference between the two digipeaters maximize 
the coverage provided by the pair. 


The call used at the Mt. Beacon site is WB2KMY-l, 
and the call at the Mt. Ninham site will be KG10- 
9. If you are located in northern New Jersey, 
Northeastern Pennsylvania or Western New England, 
check out these new facilities. (Leave reports of 
coverage on the WA2RKN-2 MailBox.) 


If you are not in New England, there is still 
something of value here; packet repeaters, unlike 
Z-meter voice repeaters, must coexist on a single 
frequency. If several clubs in one area are 
interested in packet radio, it is important that 
they work as a team to provide valuable and 
useful coverage. Lack of cooperation can only 
lead to a congested local-area network. 


via WB2KMY. 


WESTRET IN MONTEREY 


Packet operations in Monterey, CA, have improved 
due to the addition of a 6-element Yagi at the 
K6LY digipeater site. Buzz Shaw, WAINHP, 
reports that the Monterey packet operators are 
also looking into a site on Mt. Toro, at an 
elevation of 3500 feet. This would be a real 
improvement over the current site, which is only 
110 feet above sea level. However, even at the low 
elevation, stations using K6LY can usually connect 
to Hank Magnuski, KA6M, and use his Data General 
computer system. 


Via WAILNHP 


ILLINOIS PACKET MEETING 


Twenty-five people, representing networks in 
Central Illinois, Southern Illinois, Chicago and 
St. Louis, attended the December 2 meeting of the 
Central Illinois Packet Radio Users Society 
(CIPRUS), The administrative portion of the 
meeting resulted in a statement of the club’s 
intent “to promote packet radio throughout 
Illinois by acting as a clearing house for packet 
inf ormat ion, and to work for reliable packet 
communication within Illinois.” 


After electing club officers, those present took 
up a discussion of packet-radio operating 
practices. Since packet radio is new to amateur 


what constitutes “good operating procedure.” In 
particular, there is still no agreement as to when 
it is appropriate to send out CQ or QST messages. 
Broadcasting such frames through wide-coverage 
digipeaters has started to significantly slow 
traffic on several crowded networks. However, 
those at the CIPRUS meeting agreed that QST 
packets used as propagation indicators or to carry 
news bulletins were reasonable. They also decided 
that CW identification is not necessary and should 
be discouraged. [Close examination of sect ion 
97.84 of the FCC Amateur Radio Service Rules shows 
this to be an acceptable decision.-- Ed.] It was 
observed that application or common sense by 
packet operators would significantly reduce 
network congest ion. 


The CIPRUS meeting closed with the distribution 
of the the national Packet User’s Directory as 
compiled by N9AGC and available 

through CIPRUS. 


Via KONG. 


PACKET MAP 


Paul Barnett, N@CRN, placed the following message 
on DRNET: 


“lm compiling information on existing amateur 
packet networks to use at an upcoming packet-radio 
demonstration. I want to be able to show a large 
map of North America that is sufficiently detailed 
to explain multiple digipeaters and show how 
packet-radio networking is progressing. 


“I would like everyone to send me information 
about their local network, so that I can generate 
the map. Please confine the listed stations to 
those with wide coverage. I’m not particularly 
interested in the 50 stations within 25 miles of 
each other in a metropolitan area. What I am 
interested in is the stations that make up a link 
into another metropolitan area. 


"I'd like to hear about all forms of networking: 
VHF (EASTNET, SOUTHNET, WESTNET), HF (particularly 
gateways and scheduled traffic handling 
operations) and OSCAR teleports. 


“Confine your descriptions to reliable links, 
noting those that are not available 24 hours per 
day. Please limit information about planned links 
to those that will be a available by the end of 
the year. 


“When I get the map done, I will try to reduce it 
to a single page and make it generally available. 


Send information about your local network to 
Paul Barnett, N#CRN 
130 Demont Ave. East, Apt. 255 
Little Canada, MN 55117 

or to Gateway at the ARRL. 


Via DRNET. 


PACKET APPLICATIONS: WEATHER 


K6AAG>QST:HIDESERT WX 1100/52/SCTRD/VIS10HZ/SSE10- 
15/29.71/"Robbie" 


Although running in an attended and manual mode 
now, the above is an example of vhat could become 
an automated service as packet radio continues to 
grow and rules continue to change. 


For those who need help in interpretation (as I 
did), the above QST frame says that the veather in 
Southern California’s high desert region at 11:00 
was 52 degrees, scattered clouds, visibility 10 
miles with haze, winds from the south southeast at 
10-15 knots, barometer 29.71 inches. Bobbie 
Wohosky, K6AAG, the originator of the message, is 
active in the California veather net on 75 meters. 
He currently summarizes the information gathered 
by this net and distributes it via BTTY. He is 
now looking into ways to use packet radio as well. 
It is probably a safe bet that amateur-gathered 
weather information will be part of the data 
stream as regional and national digital netvorks 
take shape. 


[If you have thought of any interesting 
applications of packet radio, please send them 
along to Gateway. -- Ed.] 


From NK6K. 


PACKET READING 


Paul Newland, AD7I, points us toward IEEEK’s 
Communications Magazine, an IEEE monthly 
publication that features tutorial technical 
discussions about communications concepts and 
systems. (Don’t confuse it with IEEE Transact ions 
on Communications, a mathematical and theoretical 
journal.) The December issue of Communications 
Magazine contains the following articles of 
interest to packet-radio enthusiasts: 


“Automatic-Repeat-Request Error-Control Schemes,” 
by Shu Lin, Daniel Costello, Jr., and Michael 
Miller. Error detection incorporated with 
automatic-repeat-request (ARQ) is widely used for 
error control in data communications systems. 
[Including packet radio. -- Ed.] This method of 
error control is simple and provides high system 
reliability. If a properly chosen code is used 
for error detection, virtually error-free data 
transmission can be attained. This paper surveys 
various types of ARQ and hybrid ARQ schemes, and 
error detection using linear block codes. 


“Improving on Bit Error Rate,” by Virgil I. 
Johannes. On the semantics of the term -- its 
invalidity in the absence of a specified averaging 
period. 


“Digital Signaling Techniques,” by William 
Stallings. A comparison of various encoding 
techniques with an eye to superior performance. 


Also look into the November, 1984 issue of 
Proceedings of the IKEE. This special issue on 
satellite communication networks contains an 
article titled “Packet Switching for Mobile Earth 
Stations via Low Orbit Satellite Network.” 
Remember, PACSAT is a low-orbit packet satellite. 


R.F. Design magazine for November/December, 1984 
contains the conclusion of a series called “RF 
Modems.” This article addresses the design and 
use of frequency agile modems. Several block 
diagrams and schematics are presented. 


The December, 1984 issue of Telecommunications is 
a special issue on data communications systems, 
and contains several articles that packet 
experimenters might find interesting. 


Via AD/I, KA9Q, Ed. 


MISSING GATEWAY. 


When you subscribed to Gateway, you probably 
subscribed for 25 issues. few quick 
calculations will tell you that there should be 26 
issues in a 52-month year. The missing issue is 
to allow me to take some time off around the 
New Year. Therefore, there will be no Gateway 
dated January 1, 1985. Look for Gateway issue 11 
on January 15. I hope that you all have safe and 
en joyable holidays. 


Jeff Ward, K8KA 
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PACKET NETWORK COORDINATION 


The frequency-coordinating body for Northern 
California, NARC, has officially coordinated the 
following frequencies for packet radio: 145.01, 
145.43, 145.05, 145.67, 145.69, 223.56, 223.50, 
223.6, and 441.699 MHz. It is unclear what this 
means for current activity on 146.58 MHz. 


NARC has also requested that all “mountain-top 
digipeaters placed on the assigned frequencies be 
coordinated through NARC, to insure proper record 
keeping.” This brings up the question of where 
the jurisdiction of the frequency-coordinating 
council ends. Hank Nagnuski, KA6M, of the Pacific 
Packet Radio Society makes the following 
suggestions: 


“The [ frequency-coord inat ing counc ils | are dealing 
with very real problems of crowded frequencies, 
overlapping repeater coverage, intermod, etc. It 
is a good ideathat packet frequencies be 
coordinated through such councils. 


“However , once frequencies have been allocated to 
packet radio, the jurisdiction of the frequency- 
coordination council ends, and another type of 
advisor is needed. This advisor must help track 
and promote the rational growth of packet radio 
equipment, repeaters, gateways, and protocols on 
the assigned frequencies. The advisor may 
eventually supervise the growth of the packet 
network. 


“Therefore, I would like to propose a new term for 
amateur radio: ‘Network Coordinating Agent (NCA). 
The NCA for a region deals with the problems 
mentioned above, and also represents its area in 
national discussions of protocols and other 
issues, 


“The Pacific Packet Radio Society, because it is 
the oldest and largest packet-radio club in the 
Bay area, has become the Network Coordinating 
Agent for the San Francisco area.” 


The need for NCAs has also been recognized on the 
East Coast. Groups from New England and from the 
Mid Atlantic states agree that congestion on 
145.91 MHz must be dealt with in an organized 
manner. The first EASTNET NCA is the newly-formed 
Mid-Atlantic Packet Radio Counce il. This counce il 
will coordinate for MD, DE, Southeastern PA, 
Southern NJ, Northern VA, and Washington D.C. 


Send Gateway any comments that you have on the 
need for NCAs. 


From KA6M. 
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HIGH-SPEED PACKET PROGRESS 


At the January 12 meeting of the Chicago Area 
Packet Radio Association, Steve Goode, K9NG, 
demonstrated his 969$-bit/s, 226-MHz modems. When 
the plans for Steve’s modems become available 
(perhaps early this spring), it should be possible 
to reduce some of the congestion on Z-meter 
metropolitan packet networks. 


The modems are built around inexpensive H amtronics 
FM-5 transmitter and teceiver strips. The 
addition of a “data filter” in the modulator gives 
the FSK signal desirable spectral characteristics, 
while a corresponding circuit in the demodulator 
converts the data back to something that a TNC can 
understand. 


Congratulations to Steve for spending the great 
amount of time necessary to design and debug the 
modems. The entire packet-radio community will 
benefit from his work. 


Ed. 


There has been a lot of activity with the Data 
Communications Experiment (DCE) aboard the UO-11 
satellite this week. In preparation for a 
possible demonstration of the PACSAT store-and- 
forward “mailbox” concept, software for a 
prototype message handling system has been 
uploaded to the satellite. Monitor U0-1l1 
bulletins to look in on the action. 


Vis NK6K. 


HDLC ADD-ON AVAILABLE 


Those of you experimenting with level-3 packet 
networking should note that a High-level Data Link 
Controller (HDLC) add-on is now available for the 
Xerox 829 computer. This piggyback “FAD board” 
performs many of the complicated tasks involved in 
transmitting and receiving AX.25 frames. This 
development is particularly important because the 
ARRL Ad Hoc Committee on Amateur Radio Digital 
Communication agreed that the Xerox 829 with the 
HDLC add-on would be the standard computer system 
for level-3 software development and testing. 


TAPR now has a limited number of the add-on boards 
available, intended primarily for those doing 
level-3 experiments. Each pc board comes with a 
parts list, a schematic, and a brief survival 
guide. All told, there are only 2 pages of 
documentation; this unsupported product is offered 


only as a service. Parts for the board are not 
available from TAPR at this time. If you are 
still interested, the price is $25. 


Via WA7GXD. 


1226-—MHZTERS 


Scott Miles, WB6PQM, is establishing two new 229- 
MHz digipeaters in the San Francisco Bay area. 
The new simplex machines will be running on 223.58 
MHz, and are intended to serve the needs of RACES 
in Contra Costa county. The digipeaters will be 
based on GLB PK-1 TNCs. 


Rich Collins, NT6V, reports that he and David Bly, 
WD6EVM, have installed a digipeater on 220.58 MHz 
in San Leandro, CA. This site, made available by 
the Alameda County RACES group, provides good 
coverage of the Bay area. 


Via KA6M. 


VADCG AX.25 DIGIPEATERS 


Those of you who are using VADCG TNCs as 
digipeaters should be interested to know that Les 
McClure, W3GXT, and Mike Bruski, AJ9X, have fixed 
many of the program bugs that make these 
digipeaters fail regularly. In addition, they 
have installed some software and hardware timers’ 
which make certain that the program can recover 
from any faults that occur. 


Mike and Les would like to hear what other groups 
around the country are doing with the venerable 
old VADCG boards. If you want a copy of their 
“bullet proof” VADCG AX.25 digipeater code, send 
an 8" SSDD disk to 


Tom Clark, W3IWI 
6388 Guilford Rd. 
Clarksville, MD 21029. 


Via DRNET; 


MAIL FORWARDING IN EASTNET. 


Several more stations have joined those capable of 
automatically forwarding and receiving messages 
via packet radio. In the Mid-Atlantic section of 
EASTNET, Gary Hoffman, AK3P, is operating W@RLI’s 
MailBox program. From Gary’s station in 
Hummelstown, PA, traffic is forwarded through 3 
digipeaters to the W3IWI MailBox that serves 
Baltimore and Washington. The W3IWI MailBox is 
able to forward messages to WB2MNF in southern New 
Jersey. At a recent meeting, members of the Mid- 
At lant ic Packet Radio, Counc il (MAPRC) agreed that 
“the linked PBBSs are providing a very necessary 
communications conduit for MAPRC," 


In the northern portion of EASTNET, Jerry 
Koniecki, WA2RKN, located in Hyde Park, NY, is 
providing MailBox service to stations from Long 
Island up the Hudson River valley. The W1AW 
packet bulletin-board system has been made fully 
compatible with the W@RLI forwarding software and 
is in communication with both WA2RKN and W@RLI (in 
Boston). 


A long-standing goal of EASTNET is to link New 


England with the Mid-Atlantic. It looks like a 
well-placed station in Northern New Jersey would 
be able to complete that connection. 


For further information on the message forwarding 
protocol being used, contact Gateway or Hank 
Oredson, W@RLI. 


Via W3IWI, Ed. 


CENTRAL STATES PACKET NET 


The Central States Packet Radio Users Group Net, 
sponsored by the Central Iowa Technical Society 
(CITS) has moved from 4% meters to 75 meters. The 
new frequency for the net is 3865 kHz, and the 
time remains 1599 CST on Sundays. The net will 
continue to discuss items of general interest to 
packet-radio operators, but will concentrate on 
discuss ion of linking and networking in the 
Midwest. 


The first session of the net on its new frequency 
was January 13, and Ralph Wallio, WO@RPK, reports 
that stations checked in from Michigan, Illinois, 
Iowa, and Nebraska. Experimenters from Nebraska 
would like to encourage stations from the Rocky 
Mountain area to check in, and stations in 
Illinois would like to hear from packet operators 
in Indiana. 


Ralph suggests that Midwestern packet enthusiasts 
adopt 3865 kHz as an informal “calling frequency.” 
Operators who want more information on packet 
radio, or who are having trouble with their packet 
equipment could just give a call on 3865 kHz and 
get their quest ions answered. 


From W@RPK. 


ee eee 0 gegen 


Eastern Massachusets Sect ion Manager Luck Hurder, 
WA4STO, adds these facts to the ongoing 
discussion of NTS recognition for packet-radio 
traffic nets: 


“I was startled to see the article regarding NTS 
packet nets in the December 4 issue of Gateway. 


“According to the article, the STM of the Southern 
Florida section has stated that monthly net 
reports are the key criteria for acceptance of a 
packet net as a NTS net. 


“I certainly don’t wish to be a wet blanket about 
all this; please understand that I am an active 
packet operator. To be fair to anyone wishing to 
attempt to have their packet net become an 
official part of the National Traffic System, 
however, there are a few ground rules that must be 
taken into account. Some of them are: 


"1. The Net Manager must be appointed by the 
Section Manager or his Section Traffic Manager. 


a The Section net must adhere to section 
boundaries. 


"3, The net must function on the basis of a 
prescribed, orderly traffic flow. 


“4, The net must interface in a prescribed manner 


8) Expansion interface for Board Three (described 
below). 


“This will run on 5 v, DC and has RS-232 
compatible port6 for the two asynchronous channel6 
that are part of the 64180 microprocessor. The 
serial interface will meet the proposed WESTNET 
es tandard . 


“But, you may ask, what good is a NNC without 
modems? Glad you asked that! 


“Board Two, to go to St. Louis next week, consists 
of: 


1) Multiple XR2206/XR2211 modems. [Like the 
modems in existing TAPR TNCs.] Each modem 
will have a clock generator, a state machine 
and a tuning indicator. Board size 
constraints will determine whether we only get 
two modem6 or if we can squeeze on four modems 
per card. 


"Yes, these are only 1200-baud (or 300-baud) 
modems. But, the local users need a port or two 
to get in (1200 baud) and long-haul stuff is going 
to be HF for a while to come (300 baud now, 
perhaps 1200 later). 


“Both of these boards to be sized per the WESTLINK 
standard, so that they can screw on the side of a 
5.25-inch floppy-disk drive. 

“Why a floppy drive? I’m glad you asked that, 
too ! 


“Board Three is a plug-in floppy-disk interface! 
The I/O is mapped to be compatible with the SB180 
to allow a simple port of the "Z" system [disk 
operating system]. Thus, the NNC can become its 
own software development engine, and the hard work 
of placing a decent operating system on the NNC is 
already done and readily available at a reasonable 
price . 


"Tf we are lucky, all boards will be laid out by 
the end of September. Prototype boards should be 
populated in October, then debugged by hardware 
types while the software types (I hope) will get 
cranking on some level-three [networking] 
software. 


“Thank you each and every one for your inputs to 
date. Keep the comments coming. Happy 
packeting!" 


[lf you are interested in what the 64180 
microprocessor is like, be sure to read the 
referenced Byte article. For further, still 
introductory, discussion of some of the computer 
hardware concepts introduced in the above item, 
read chapters 8 and 19 in the 1985 ARRL Handbook. 
-- Ed.] 


Via DRBNET. 


MAPRC MEETING REPORT. 


The Mid-Atlantic Packet Radio Council (MAPRC) met 
on September 11, in conjunction with the 
Gaithersburg, Maryland, hamfest. The following 
item is condensed from a report filed by Mike 
Chepponis, K3MC, and Bob Hoff man, N3CVL. 


About 40 hams were present. The first hour of 
discussion concerned MAPRC organization. A copy 
of the proposed MAPRC constitution was distributed 
and discussed. It was resolved to collect $24 per 
year membership dues with $50 per year dues for 
clubs. Clubs would get two votes, and individual 
member6 would get one vote. The official purpose 
of MAPRC is to promote linking in the Mid-Atlantic 
area and to make funds and expertise available to 
install and maintain digipeaters. Projects funded 
by MAPRC will include digipeaters in areas that 
are critical to network growth, but without large 
populations of packeteers. 


The group then discussed EASTNET and MidNet 
coverage. Bob Hoffman, N3CVL, distributed copies 
of a map of MidNet and three possible paths 
between MidNet and Eastnet were analyzed: 


A) Through Northern Pennsylvania and the Buffalo 
area. This link would enter EASTNET territory 
at K3RLI in Wilkes Barre, Pennsylvania. 


B) Through Harrisburg and into Philadelphia. 
Gary Hoffmann, AK3P, is already working on 
this path. 


C) Through West Virginia. This route would enter 
EASTNET at Cumberland, Maryland, via N8FJB, 
near Martinsburg, West Virginia. 


The discussion turned to multiport digipeaters and 
whether it is best to use the 440-MHz band or the 
220-MHz band for 9600-bit/s links. 440 MHz is 
preferred by some, especially Brian Lloyd, WB6RQN, 
because high quality commercial gear is available 
for that band. Groups without well-equipped RF 
labs have had problems with the Hamtronics FM-5 
transceivers used with the K9NG 9600-baud modems. 
On the other hand, many folk6 already have some 
kind of 220-MHz equipment, and Bob, N3CVL, pointed 
out that there are other 220-MHz transceiver 
boards that are fairly easy to align. It was also 
noted that WB4JFI-5 is already on 220 MHz. There 
was some confusion as to what frequencies are 
allocated on 220 MHz and 440 MHz for packet. Some 
people are reluctant to use the high-speed (100- 
kHz) channel6 allocated on 220 MHz for narrow-band 
(20-kHz) modems. Others, pointed out the 
advantage of being able to change to higher speeds 
in the future without the need to change channels. 
It was resolved to use 220 MHz for the backbone. 


Will Xerox 820s be used as the backbone boards? 
[In the near future, the answer is probably “yes,” 
because the multiport digipeater code runs on the 
Xerox 820. -- Ed.] Discussion was inconclusive, 
but it was noted that the 820 [since it uses an 8= 
bit microprocessor] is running out of steam. 
Possible alternatives are machines based on the 
8088, like the IBM PC, or machines with large 
linear address spaces, like the 68000. When 
choosing a second-generation networking 
controller, we must pay close attention to the 
availability of inexpensive development tools -- 
in particular, compatible computers on which 
software can be written and tested. 


Brian Lloyd and Phil Karn, KA9Q, discussed some 
technical aspects of the network. For example, 
making FRACK [the time that a TNC waits before 
retransmitting a packet] and DWAIT [the time that 
a TNC waits after the channel is clear before 
transmitting] fairly large number6 really help6 
out on busy or noisy channels. There was some 
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LOW-POWER TNC FROM GLB 


GLB Electronic6 has released its PK-1L TNC. The 
PK-1L is an enhanced, CMOS version of the 
successful PK-1 TNC. Running with a CMOS Z80A 
microprocessor, the PK-1L draw6 only around 25 ma, 
and it can even be run on a 9-v transistor 
battery. GLB engineer Ed Jackson, WB20IF, 
estimates that the PK-1IL would run for about 20 
hour6 from a 9-v alkaline battery. This TNC 
should be great for solar-powered operation. As 
well as supporting all the features of the PK-1, 
the PK-1L will have an on-board watchdog timer, 
battery-backed-up RAM to store operating 
parameters in case of power failure, standard DB- 
25 connectors for radio and terminal I/O, a bit on 
the radio connector that indicate6 whether the TNC 
is connected, and two spare I/0 bits available for 
later expansion. The TNC comes assembled and 
tested, in a 4.5 X 6 X l-inch, all-metal cabinet. 
It should make a great portable or remote station. 


Prom WB20IF. 


TAPR NETWORK CONTROLLER 


The availability of several commercial TNCs has 
spurred the growth of packet radio. In most 
areas, several new calls are heard on the air each 
week, and Gateway is getting between 50 and 100 
new subscribers per issue. How will these new 
users be served by the existing network? 
Moreover, how will network continue to offer more 
services in the face of a steadily growing user 
community? The single-frequency amateur packet- 
radio network is already nearly overloaded in many 
metropolitan areas. When the network become6 
overloaded, the packet community will look to its 
experimenters for new hardware and software to 
keep packet radio growing. 


Several groups of experimenters, both formal and 
informal, are investigating the various hardware 
and software choice6 that face the amateur packet- 
radio community. The necessary software include6 
protocols for network (also called I80 layer 3) 
and transport (180 layer 4) services, and 
standards for addressing, routing and mail 
forwarding. Hardware will be needed for 
sophisticated mountain-top digipeaters, remotely 
operated PBBSs, satellite teleports and HF-to-VHF 
gateways, While Gateway is a newsletter and not a 
technical journal, much of the packet-radio news 
in the next few months will concern the projects 
and s tandards mentioned above. When these topics 
are covered in Gateway, we will try to define 
terms as we introduce them, to stick to newsworthy 
items, and to list sources of more extensive 


information. 


Sept. 17, 1985 
Vol. 2, No. 3 


One of the groups interested in what is broadly 
called “networking hardware,” is TAPR. Now that 
several hundred TAPR TNC 26 have been shipped, 
TAPR is turning to the design and debugging of a 
Network Node Controller (NNC), TAPR president 
Lyle Johnson provide6 the following overview of 
the TAPR NNC project. 


"To keep everyone in the loop, here is the present 
status of the TAPR NNC hardware project. 


“The schematics are in St. Louis at 
Interconnections, the company that does all the 
CAD (computer-aided design) layout work for TAPR. 
If all goes well, we should have artwork for all 
three boards by the end of the month! 


“Board 1 is the NNC itself. 
configuration is a6 follows: 


Its present 


1) HD64180 microprocessor. This is the CMOS 2Z80 
superset chip with on-chip DMA (direct memory 
access), dual UARTs [for asynchronous 
communication6 ], 16-bit timers, MMU (memory 
management unit) [to manage 512 kbytes of 
memory] and a clock. This is the same 
microprocessor that is featured in “Build the 
§B180 Single-Board Computer” in the September 
issue of Byte magazine. 


2) Dual SI0/2s. This allows four channels of 
HDLC (high-level data link control) 
capability. [HDLC is necessary for packet 
operation.] One SIO may be configured (via 
push-on jumpers) to have either or both of the 
channels operate DMA. 


3) One PIO (parallel I/O) chip. This provide6 a 
parallel printer port and several lines to 
fiddle with (for bells, whistles, buzzer6 and 
item 4). 


4) A battery-backed-up real-time clock. 


5) An SCSI interface, which allows this board to 
communicate at high speed with other nearby 
devices. This will allow the NNC to be a 
smart Level Two “front end” for a later board 
that can handle all the networking and 
transport functions when the network outgrows 
the capacity of the 64180. 


6) Eight byte-wide sockets, for 64 kbytes of 
battery backed-up RAM (bbRAM) with jumper 
selection for 256k bytes of bbRAM! 


7) Eight more byte-wide sockets mapped for 32- 
kbyte parts. ..This allows the full 1/2 Mbyte 
of memory to be put on the board. 


packet radio. As this activity pick6 up, don’t 
forget to send us item6 of interest. Gateway 
would like to supply up-to-date packet-radio news. 
To do that, we need to know what is going on in 
your part of the network. You can send this 
information through the mail, via DRNET or via 
Compuserve HAMNET (ID 75105,737). If you have any 
comments on how we can better serve you through 
Gateway, send those along too. 


This copy of Gateway was delayed by the Labor Day 
holiday. Previous issues of Gateway, however, 
should have been delivered regularly -- none more 
than a day or so late. If you are having erratic 
delivery, especially if your Gateway comes via 
First Class Mail, please send usa letter 
detailing the problem. If your Gateway is mailed 
at bulk rate, there is no way to combat delivery 
de lays. 


Kd. 
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advantages, the digipeater and the TNC. The 
second part of the article will describe packet- 
radio equipment and applications. 


John’s article includes a sidebar on the his tory 
of packet radio, which shows how radio amateurs 
have influenced and developed packet-radio 
t echno logy. At the end of the sidebar, John says 
that he “believes those of us in the business 
radio environment would do well to avoid 
encroachment on [the 220-MHz] and other amateur 
experimental bands. The results of work carried 
out on amateur frequencies may yield decided 
benefits for the commercial sector.” The 
editorial comment in the magazine that carried 
John’s article states: “We welcome the opportunity 
to tell the story when amateurs help commercial 
users by way of experimentation. We avoid 
contrasting amateurs with ‘professionals. 


Packet radio is bringing Amateur Radio a lot of 
favorable attention from communications 
professionals. Congratulations and thanks to John 
Gates and the others who have had papers about 
amateur packet radio published recently in the 
professional press. 


Ed. 


CONNECTICUT PACKET CLUB FORMED 


On September 3, the Southern New England 
Association of Packeteers (SNAP) adopted a 
constitution and formally became a club. SNAP 
hope8 to organize the growth of packet radio in 
Connecticut. The club will meet on the first 
Tuesday of every month at 7:30 PM at ARRL 
Headquarters, Newington, Connecticut. 


For further information, write: 


Jon Bloom, KE3Z 

c/o ARRL 

225 Main Street 
Newington, CT 06111 


From WA2FTC. 


JAPANESE PACKET 


The following update on Japanese packet radio 
comes from Tac Okamoto, N6MBM/JA2PKI. Tacis 
temporarily living in Irvine, California, and is a 
regular on Compuserve HAMNET. 


"You are interested in packet activity in Japan. 
Hummmm.. Where should I start? A couple of 
years ago, a group called JAMSAT received a pair 
of TAPR beta-test TNC boards. As you may know, 
JAMSAT is a group like AMSAT, working to build the 
first Japanese amateur-radio satellite, JAS-1. 
JAS-1 has a packet-radio transponder [See 


Gateway 
issue 23]. When TAPR started distributing the TNC 


1, JAMSAT bought 6 of them to use as development 
tools for JAS-1. Those TNCs were also used for 
JAMSAT’s information network, JASNET. JASNET was 
the first packet-radio net in Japan. Now JAMSAT 
has finished hardware for two JAS-1 satellites. 
Yes, JAMSAT has built two JAS-ls. One of them 
will be launched in August, 1986. [The other one 
will be a back up. -- Ed.] So, the packet 
activity in Japan was started by JAMSAT with help 
of AMSAT and TAPR. 


“Can Japanese amateurs buy a Japanese TNC? Yes, 
they can. A company in Japan bought a 
manufacturing license from AEA and is making a 
TAPR TNC 1/AEA PKT 1 clone. The TNC costs around 
$300. 


“How many TNCs are in Japan? I don’t know 
exactly, but there may be 300 or more. Do they 
send and receive Kanji [Japanese alphabet] via 
packet? Yes, there is even a a Kanji BBS!" 


Via HAMNET. 


K9NGMODEM PROJECT. 


The modem design presented by Steve Goode, K9NG, 
at the Fourth Amateur Radio Computer Networking 
Conference generated a lot of excitement among 
packet-radio experimenters. The 9600-bit/s modem 
is necessary for planned intercity “trunk lines” 
or “backbones.” Since Steve’s presentation at the 
conference, TAPR has been working on making 
available a PC board and a kit of hard-to-find 
parts for the circuit. The project took a little 
longer than expected, but the PC boards have been 
tested, and the final package should be ready for 
shipping before the end of this month. The PC 
board is designed to connect a TNC and a 
Hamtronics FM-5 220-MHz transceiver. Other 
transceivers can be substituted, with appropriate 
modif ications to the modem board. TAPR will not 
be selling a complete kit of parts for this 
circuit. The boards will probably come with the 
critical capacitors and the state-machine PROM. 
This will not be a step-by-step project for the 
beginning kitbuilder, but the documentation 
provided with the board and the article that Steve 
submitted to the Proceedings of_the Fourth ARRL 
Amateur Radio Computer Networking Conference 
(available for $10 from the ARRL) should allow 
experienced builders to assemble and test the 
modem, When the kits are available, announcement 
will be made in Gateway and on packet-radio and 
telephone bulletin boards. 


Ed. 


HAWAIIAN ERRORS 


In the last issue of Gateway, we incorrectly 
stated that Maui is the largest of the Hawaiian 
islands. Several people have pointed out that 
Hawaii is the “Big Island” and Maui is the second- 
largest Hawaiian island. The link discussed in 
the Gateway item was between Hilo, Hawaii, and 
Kalaheo, Kauai. Maui was not involved. 


Ed. 


GATEWAY ADMINISTRATIVE NEWS 


Now into its second year, Gateway is as successful 
as we had hoped it would be. There are now over 
860 paid subscribers to the newsletter, and 
several hundred officials of NTS and other ARRL 
field organizations receiving complementary 
copies. We believe that another thousand people 
receive electronic copies of Gateway from packet- 
radio or telephone bulletin boards. 


Now that the summer is over, people will be 
returning to their shacks and getting back into 


Bill Stash, WA3A0Q 
421 Daily Drive 
North Huntington,, PA 15642. 


Prom AK3P. 


PACKET SOFTWARE AVAILABLE ON BBS 


The WORLI MailBox/Gateway program and the KE3Z 
multiport digipeater program are now available for 
downloading from the Ham Radio Net BBS in 
Newington, Connecticut. Ham Radio Net, run by Ed 
Raso, WA2FTC, can be accessed at either 1200 
bauds or 300 bauds, and it is usually in service 
around the clock. 


All cf the files necessary for configuring and 
running version 10.0 WORLI MailBox and Gateway are 
on the Ed’s system, as are all of the files that 
you would receive if you sent a disk to the ARRL 
for the multiport digipeater code. These files 
are stored in File Area 2 of the BBS -- the Packet 
Radio Section. Because the programs and 
documentation are large, they have been squeezed 
and placed in library files. The program that 
will unsqueeze and separate them is the CP/M 
utility NULU11. NULU11 is also in File Area 2 on 
the Ham Radio Net. 


Distributing WORLI’s software electronically 
should allow new versions of the popular MailBox 
and Gateway to spread rapidly. Hank Oredson, 
WORLI, has put a lot of time into support of his 
software, and the latest release, Version 10.0, 
has several useful new features. 


You can call Ham Radio Net at: 
203-665-1114. 
Via WA2FTC, KE3Z. 


EASTNET UNIX UPDATE 


Several improvements have been made to the UNIX- 
based news and mail gateway run by Jim Kutsch, 
KY2D. [See Gateway Issue 19.] Jim reports that 
the system, running as KY2D-2, is now operating 24 
hours per day on 145.01 MHz. It can be reached 
reliably through the WA2VKH, WA2SNA-2 and WB2VIN-1 
digipeaters. There are 10 frequent users of KY2D- 
2 as well as several casual users. 


Jim has recently developed and installed software 
that will accept automatic forwarding of mail and 
bulletins from systems running the WORLI MailBox 
program. Mail received by KY2D-2 can be further 
forwarded into the USENET (an international 
network of UNIX systems), if the correct USENET 
address is included as the first line of the 
message. 


Right now, mail is accepted only from the WA2VKH 
MailBox, but the system can be instructed to 
receive mail from any MailBox. You do not need to 
modify the WORLI software in order to forward to 
KY2D-2. 


[UNIX is a trademark of AT&T Bell Laboratories. ] 


From DRBNET. 


If you are frustrated by the difficulty of tuning 
in HF packet stations, you may be looking for a 
good FSK tuning indicator. An interesting crystal- 
controlled digital tuning indicator is described 
in an article called "RTTY Tuning: The New 
Solution,” by John Langner, WB208Z in the March 
1983 issue of 73 magazine. John also discusses 
the design in.he August issue of the NEPRA 
PacketEar, newsletter of the New England Packet 
Radio Association. The tuning indicator is 
actually a simple frequency counter that display6 
the mark and space frequencies on an LED bar 
graph. It look6 useful, and it should be 
inexpensive. If you read the article and want to 
build one of the indicators, Jon has a few PC 
boards available for $10. 


Contact: 


John Langner, WB20SZ 
115 Stedman Ct. 
Chelmsford, MA 01824. 


From The NEPRA Packet£Ear. 


GEORGIA CLUB ADDRESS 


The address for the Georgia Radio Amateur Packet 
Enthusiast Society (GRAPES) that was previously 
published in Gateway is no longer valid. The new 
address is: 


GRAPES 
P.O. Box 1354 
Conyers, GA 30207. 


Ed. 


BF GATEWAY LIST 


Don Simon, NI6A, is compiling a list of HF gateway 
stations. If you operate an HF gateway, even part 
time, send a letter to Don. Be sure to tell him 
your station callsign, location, coverage and 
hours of operation. 


Don is also discussing with William Smith, W7GHT, 
the use of packet radio to pass messages to 
Australia and New Zealand. The two are looking 
for HF packet stations that might be able to 
connect to stations in those countries. 


If you can assist with either of these projects, 
contact: 


Don Simon, NI6A 
2327 Alva Avenue 
El Cerrito, CA 94530. 


From NI6A. 


MOBILE RADIO TECHNOLOGY ARTICLE 


If you are looking for an article that describes 
packet radio to people who are familiar with 
communications but not with amateur radio, look at 
“Packet Radio Combines Computer, RF Technologies,” 


in the August 1985 issue of Mobile-Radio 


Technology. This article, written by John Gates, 
N7BTI, describes the basics of packet radio, its 
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THC 2 HITS THE MARKET. 


The long-awaited Tucson Amateur Packet Radio 
(TAPR) TNC 2 went on sale August 19, as scheduled. 
Volunteers staffed the TAPR office from 9 AM to 9 
PM throughout the week, and at the height of the 
ordering rush, a TNC-2 order was processed every 
three minutes. The number of phone calls coming 
into Tucson on the 19th and 20th overloaded the 
Tucson telephone center several times. Callers 
had to be both persistent and lucky to place one 
of the first 300 orders. Those first callers have 
already received their TNCs. Those that weren’t 
in the first 300 orders will receive their TNCs 
from a mid-September and an October shipment. 
TAPR has accepted 832 orders. Packeteers from all 
over the U.S. and from foreign countries on every 
continent ordered TNC 2s. 


The kits have gone together easily, although IC 
sockets damaged in shipping and some faulty ICs 
have hampered the assembly of some TNCs. If you 
have built a TNC 2 and it passes all tests up to 
the power-up LED sequence, you may have a bad IC 
at U13. TAPR has always had a policy of replacing 
defective parts, and will continue to offer this 
support. If you suspect that have a bad IC, call 
the TAPR office and they will send you a 
replacement 74HC4066. New packaging for the kits 
should protect IC ‘sockets from damage. 


Comments on the documentation, which includes an 
extensive introduct ion to packet operation, have 
been positive. The software, with a real-time 
clock and a new, more-informative monitor mode, 
has also gotten good reviews. 


Tom Clark, W3IWI, one of the TNC-2 beta testers, 
has compiled some notes on operating and 
customizing the TNC 2. These notes are posted on 
many packet bulletin board systems (PBBSs) around 
the country, as well as on some telephone BBSs. 
Further notes, along with suggestions and comments 
from kitbuilders will appear in the October issue 
of the Racket Status Register, quarterly 
publication of TAPR. If you want immediate up-to- 
the-minute information on TNC 2 and other 
developments in packet radio, consider joining the 
HAMNET (part of the Compuserve on-line information 
service). 


Kd. 


220-MHz FREQUENCIES FOR 1200 BIT/S 


The ARRL is interested in finding out what 
frequencies are allocated for or used for 1200- 
bit/s packet operation on 220 MHz. Art Reese, 
K9XI, editor of 220 Notes would like publish this 
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information so that his readers will know where to 
expect packet-radio operation. If you are 
operating at 1200 bauds on 220 MHz, or if a 
frequency-coordinating body in your area has 
allocated a channel for low-speed packet radio, 
send the information to Gateway. 


Ed. 


CALL FOR PSB ARTICLES 
Submissions for the October issue of the TAPR 


editor by September 15. The issue will include 
TNC 2 news, updates on TAPR projects, and 
discussions of linking hardware and software. Of 
course, articles covering other topics, especially 
articles on the history of packet radio, are 
welcome. 


Editor of the PSR is Gywn Reedy, and his address 
is: 


812 Childers Loop 
Brandon, FL 33511. 


Via DRNET. 


PENNSYLVANIA SITES NEEDED 


In late July, packet-radio operators from West 
Virginia, Ohio and Pennsylvania met in Breezewood, 
Pennsylvania. The meeting was organized by Gary 
Hoffmann, AK3P, and Bill Stash, WA3A0Q, and was 
attended by 14 other packeteers. The discussions 
at the meeting centered on how to link EASTNET to 
Pittsburgh, Pensylvania, and then into Ohio. 


Several of the operators from Ohio reported that 
they can regularly work east into Pittsburgh, but 
there is still no link between Pittsburgh and 
Harrisburg, the western outpost of EASTNET. Those 
at the meeting agreed that a digipeater at Blue 
Knob, Pennsylvania, would be ideal. An amateur- 
radio voice repeater on this site has very good 
coverage of the central part of the state. Nobody 
has been able to get permission to place a 
digipeater on this site yet. 


If you have access to a digipeater site that can 
put a good signal into both Harrisburg and 
Pittsburgh, please contact: 


Gary Hoffmann, AK3P 


1235 Middletown Road 
Hummelstown, PA 17036, 


or 


SOUTHERN CALIFORNIA CLUB ORGANIZES 


Packet-radio users in Riverside and San Bernardino 
counties are organizing the Southern California 
Amateur Packet Radio Assiciation (SCAPRA). The 
first Meeting of SCAPRA will be held on August 27, 
at 7:00 PM, in the lobby-level amphitheater at 
Loma Linda University Medical Center. A talk-in 
station will be on the 147.735-MHz LLUARC 
repeater. 


SCAPRA hopes to distribute packet information, 
coordinate packet activities and promote friendly 
expansion of packet radio. 


For more information, call: 


Rod Wertz, WC6T 
714-796-2883 


From HI6A, HAMNET. 
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will be held on the campus of Georgia Technical 
University, in Atlanta. Technical sessions will 
run Saturday from 8:30 to 5:00 and on Sunday from 
8:30 to 12:00. There will be an informal get- 
together on Friday night and an organized dinner 
on Saturday. 


Interested packeteers are invited to make formal 
or informal presentations on any topic concerning 
packet radio. If you want to participate, send 
your name, address, phone number, amount of time 
needed, a list of audio/visual equipment needed 
and a brief abstract of your topic to: 


Bill Crews, WB2CPV 
1421 Hampton Ridge Road 
Norcross, GA 30093 


From N4CI. 


On Saturday August 10, a group of 10 amateurs met 
in Columbia, South Carolina to organize a 
statewide group for hams interested in digital 
communications. The: name for the group is South 
Carolina Amateur Digital Society or SCARDS. The 
main purpose of SCARDS is to provide a forum in 
which amateur radio digital communicators can get 
acquainted with each other and exchange 
informat ion. It will also promote the orderly 
growth of packet radio and other forms of digital 
communications in South Carolina. SCARDS will 
encompass all forms of digital communication, not 
limiting itself to packet radio. The club will 
publish a newsletter every 2 months, beginning in 
September. Items for the newsletter should be 
sent to editor Al Nelson, KA4YEA. 


This item came by way of the GRAPEVINE, newsletter 
of the Georgia Radio Amateur Packet Enthusiasts. 
The GRAPEVINE also reports that on the weekend of 
August 17, a team of hams installed the W4Fx-1 
digipeater on Sassafras Mountain, the highest 
point in South Carolina. This digipeater should 
help fill the gap between EASTNET and SOUTHNET, as 
it sits midway between packet-radio activity 
centers in North Carolina and Georgia. 


Via W4FX, DRNET. 


MULTIPLE CONNECTIONS 


If you are interested in experimenting with 
multiple simultaneous connections from the same 
TNC, you will be interested in these developments. 
Multiconnect firmware written by WA8DED is already 
in use at several sites in California. Version 
0.9 of this software (for the TAPR TNC 1 and 
compatibles) is now available. This software 
offers the following features: up to four 
simultaneous connections possible, easy-to-read 
monitor mode, on-screen calibration, digipeats 
AX.25 Version 2 frames, separate status display 
for each connection and a special “host mode” for 
computer interfaces. 


Harold Price, NK6K, also has multiconnect software 
in the beta-test stage. This is part of the 
upcoming TAPR TNC 1 Version 4.0 software. Owners 
of the TAPR TNC 2 will not be left out; Howard 
Goldstein, N2WX, author of the TNC-2 software is 
testing multiconnect routines for that TNC. 


The availability of this software should spur 
development of multiuser bulletin boards and 
gateways. It will also provide a basis for 
experimentation with networking protocols. We are 
interested in hearing from anyone developing 
applications that will take advantage of multiple 
level-2 connections. 


Via HAMNET, DRNET. 


NEW PACKET CENSUS 


The following is both a report and a request from 
Harold Price, NK6K: 


“While southern California isn’t always a good 
place from which to judge how things are going in 
the rest of the world, it is interesting to note 
how quickly packet is growing around here. On our 
Monday-night nets (both voice and digital), we 
have been getting several new users each week. 
Most of them are running the Heath HD-4040 TNC. 


"TNCs seem to be selling very well. A call to a 
LA radio store revealed a backlog of orders for 
AEA TNCs. Heath is sold out of their latest 
product ion run, and they are again back ordered. 
Based on the production schedules the Heath people 
were talking about at Dayton, this means that 
they've sold around 1500 TNCs. 


“What is the new-user activity in the rest of 
North America? I would like to do another packet 
census, so send me any information that you have. 
Send reports to NK6K @ KD6SQ, via any WORLI 
MailBox that can reach an HF Gateway.” 


From NK6K. 


WESTHET PROJECTS 


Looking for something to do this winter? This 
item, which originated at the WA60SA Packet 
Mailbox, details the projects underway in WESTNET: 


0 Tom King, KA6SOX, is developing a 9600-bit/s 
FSK modem using K9NG technology adapted for use 
with Midland 220-MHz radios. Tom is also 
developing modifications for the Midland radios to 
make them more suitable for WESTNET backbone use. 


0 Greg Pierro, WA6RWN, and Jerry Brayton, 
WB6AIE, are developing a CMOS 2Z80-based processor 
board for use in remote mountaintop environments. 


0 Orv Beach, WB6WEY, is enhancing the KE3Z 
multiport digipeater software and the FAD HDLC 
daughter board for WESTNET backbone use. 


0 Andy Cromarty, N6JLJ, is drafting a proposed 
functional specification for WESTNET networking 
software. 


0 Mike Busch, W6IXU, is developing new mailbox 
software which uses the WA8DED multiconnect 
firmware. It will support multiple simultaneous 
connections and will soon include automatic store 
and forward with other mailboxes. The WA60SA 
mailbox will be converting to the new software as 
soon as it is available. 


Via HAMNET. 


and a big gap between EASTNET and SOUTHNET. To the 
west, there is significant activity from 
Pittsburgh west to Finley, Columbus, Indianapolis 
and into Chicago. We would like to investigate 
routes through West Virginia and central 
Pennsylvania. Anybody with knowledge and ideas 
about these routes should be prepared to make a 
presentation. How far away is the Golden Packet 
award? 


0 Hardware and new-user discussions. The 
newest packet radio hardware, the TNC 2 (complete 
with ALJ-1000), the Kantronics Packet Communicator 
and the AEA PK-64, will be discussed. Bring your 
new application6 software, especially terminal 
programs for common personal computers. Time will 
be allocated for discussing the problems that new 
user6 face when coming on the air. 


0 Frequency-coordination matters,boththose 
within the packet community and external matter6 
like local repeater council6 and FCC actions. 


0 Integration of packet radio into other 
aspects of Amateur Radio, particularly the 
National Traffic System, emergency communicat ion6 
and disaster relief. The recent use of packet 
systems in the California fires has raised 
questions about emergency communication and 
emergency preparedness. 


0 Packet bulletin board system (PBBS) 
discussion. What’6 happening on the PBBS front? 
How do I get a PBBS on the air in my area? How 
will PBBSs evolve in the next few years? How do 
RCP/M systems, UNIX host6 and HF Gateways fit into 
the grand scheme? This will also be a discussion 
of PBBS coordination. 


0 DX packet radio, including HF gateways, Oscar 
10, PACSAT, JAS 1 and the possible WA4SIR Space 
Shuttle packet-radio experiment. 


As at past MAPRC meetings, these discussions will 
be in “town-meeting” format; everyone will be 
encouraged to speak his or her piece. Please let 
us know if you are going to be able to come to the 
meeting. Also, contact us if there are items that 
have been omitted from the discussion topics 
listed above. 


From W3IWI. 


VADCG DEVELOPMERTS 


Although we don’t hear about them often, there are 
quite a few VADCG TNCs in operation. The latest 
VADCG news comes from Alan Mar, VE7DPM: 


The Sydney (Australia) Amateur Digital 
Communication6 Group (SADCG) has taken the VADCG 
V-2 protocol and the AMRAD implementation of AX.25 
for the VADCG TNC and merged them. This allow6 
one VADCG TNC to run both protocols. It is now 
possible to choose either V-2 or AX.25 from the 
TNC menu. Since more memory is required when you 
have both protocol6 in o1e TNC, you must modify 
the TNC to accept larger EPROMs. Alan does not 
know if the Australian6 have a version of this 
software that runs on a VADCG TNC with the AMRAD 
daughter board. 


An interesting feature of this software is the 
inclusion of a standard TNC-to-user interface. 


This interface, based on international standards 
X.38 and X.28, define6 TNC operating parameters and 
provides a protocol for displaying and altering 
them. The ARRL Ad Hoc Committee on Digital 
Communication6 is investigating the adoption of 
this protocol as an amateur standard. (See the 
proceedings of the 4th ARRL Amateur Radio Computer 
Networking Conference for further details.) VADCG 
devotee6 have developed a CP/M program that uses 
the X.3/X.28 interface to transfer binary files. 
The file-transfer protocol is TNC-independent, and 
details should be available soon. 


Via HAMNET, VE7DPM. 


WISCONSIN NEWS 


John Corstvet, WA9SOU, from Madison, Wisconsin 
provides this activity report: 


“At the July meeting of the Wisconsin Amateur 
Packet Radio Association (WAPRA) the club decided 
to move Wisconsin packet activity from 144.950 MHz 
to the national packet frequency, 145.010 MHz. 
Most station6 will have already switched 
frequencies. We are working on a digipeater at 
North Freedom, Wisconsin, which will link with 
stations in Madison, Baraboo and Portage. The 
North Freedom system should be on the air by early 
September. We are also making plans for a path 
from North Freedom to La Crosse, from La Crosse to 
Rochester, Minnesota and then north to the 
Minneapolis/St. Paul, Minnesota area. If you are 
interested in more information on WAPRA, their 
address is: 


WAPRA 
P.O. Box 1215 
Fon du Lac, WI 54935. 


Membership dues include a l-year subscription to 
Badger State Smoke Signals, which carries the 
WAPRA newsletter.” 


From HAMNET, WA9SOU. 


BARE PC BOARDS AVAILABLE 


Applied Digital Technology (ADT), of Oxnard, 
California, is selling bare pc boards for the TAPR 
TNC 1. The boards, produced from the TAPR 
artwork, are faithful copies of TNC 1. ADT is 
also selling the latest TAPR firmware, 
reproductions of the TAPR manual and some of the 
hard-to-get TNC parts. According to ADT, the 
boards are high-quality glass epoxy, solder masked 
and silkscreened with component locations. The 
company may produce pc board6 for TNC accessories. 
For further information, contact: 


Applied Digital Technologies 
2056 E. Sutter Place 

Oxnard, CA 63033 
805-488-5575. 


Via DRNET. 


SOUTHNET CONFERENCE II 


The Second SOUTHNET Packet-Radio Conference will 
be held on November 23 and 24. The conference, 
hosted by the Georgia Tech Amateur Radio Club, 


Cate Wal kia 
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HAWAIIAN ISLANDS LINKED 


The Maui County ARES Bulletin reports that Maui 
(the largest of the Hawaiian-islands) and the 
island of Kauai are now linked by two-meter packet 
radio. Bill Baisley, KH6S, and Army Curtis, AH6P, 
made the first inter-island connection, using a 
digipeater on Mauna Loa. The Mauna Loa digipeater 
is on 145.05 MHz, operating as AH6P-1. 


From WESTLINK. 


OHIO LINKING 


Thomas Kryza, KB8CI, reports another packet-radio 
first: 


“Perhaps it wasn’t an earth-shaking event, but 
nevertheless, July 14 marked a milestone for Ohio 
packeteers. Tom Kryza, KB8CI, in Cleveland, and 
Reggie Brown, KI4UN, in Florence Kentucky (just 
across the Ohio River from Cincinnati) made the 
first Cleveland-to-Cincinnati packet-radio QSO. 
The contact over the 292-mile path lasted about a 
half an hour. Two digipeaters were used: W8AC in 
Chardon, Ohio and AD8I in Circleville, Ohio. 


“The more than 80 packeteers around Cleveland and 
Akron are now connecting on a regular basis with 
Detroit, Youngstown, Pittsburgh and London 
(Ontario). We are looking for stations in 
Sandusky and Mansfield to increase the reliability 
of paths to Toledo and Columbus.” 


From KB8Cl. 


IOWA FRE CY_ COORDINATION 


From the minutes of the May meeting of the lowa 
Repeater Council: 


“A motion was made, seconded, and passed that 
145.01, 145.03, 145.05, 145.07 and 145.09 MHz be 
set aside for packet radio. A motion was also 
made, seconded and passed to change the 220 
bandplan to accommodate high-speed data links. 


“It was suggested that since we have decided to 
stay with the 15/30-kHz plan, that we also change 
the packet-radio subband from the 20-kHz plan to 
the 15/30-kHz plan so that the entire 2-meter 
bandplan is consistent. It was decided to study 
the idea and delay decision until a later date.” 


From the IRC. 


MID-ATLANTIC MEETING 


On September 7, the Mid-Atlantic Packet Radio Club 
(MAPRC) will hold a meeting in conjunction with 
the Gaithersburg Hamfest. MAPRC is primarily 
intended to act as a unified voice for packet 
radio in northern Virginia, Maryland, Delaware, 
eastern Pennsylvania and southern New Jersey, but 
anyone who is interested in packet radio is 
invited to attend. 


Saturday was selected to allow a full afternoon of 
packet-radio discussions without interruption from 
activities at the Hamfest. The meeting will start 
around 14:00 EDT, with dinner planned for 18:00. 
Meeting facilities will be available starting 
about 13:00 for informal discussions, disk 
swapping, etc. 


The meeting will be at the Baldwin Community Hall 
in Savage, Maryland. This is within a mile of the 
intersection of US 1 and MD 32, and it is 
convenient for travellers coming in on on I 95, US 
29 or the Baltimore/Washington Parkway. Detailed 
directions will be posted on major EASTNET packet 
bulletin board systems (PBBSs), addressed to the 
dummy address “MAPRC”. Talk-in stations will be on 
the Maryland FM Association 146.76/.16—-MHz 
repeater and the Columbia ARA 147.135/.735-Mhz 
machine. 


Some of the local packeteers have offered to put 
up those travelling from afar on modest budgets. 
These “luxury” accommodation6 range from tents and 
RVs to floor space suitable for sleeping bags. To 
make arrangements, please send your lodging 
requirement6 through EASTNET PBBSs to the address 
BEDS @ W3IWI. 


The meeting will address the following topics: 


0 MAPRC organization. It is time for MAPRC to 
become a “real” entity. 


o The expansion of EASTNET in the MAPRC area. 
This will include a discussion of 9600-bit/s 
linking, dual-port digipeaters and the need for 
fund6 to get an enhanced network on the air. What 
about the proposed TAPR network controller? What 
is happening with level-3 linking protocols? Will 
TCP/IP or VC get on the air first? Just what are 
level 3, TCP/IP and VC, anyway? 


0 Expansion of EASTNET north, south and west. 
From Harrisburg north through Williamsport, State 
College, Allentown, Scranton, Wilkes Barre and 
into western New York, the links are sparse. 
Stations in that area are now best reached through 
southeastern New York. South from Washington 
there is sparse activity through southern Virginia 
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Tucson Amateur Packet Radio ha8 announced that its 
new TNC 2 will be available beginning August 19. 
No order8 are being taken before the 19th. Order8 
will be taken by telephone between 9 AM and 9 PM 
PDT, August 19 through 23, and during regular 
business hour8 thereafter. There are 280 TNC 28 on 
hand at TAPR, and these will be shipped 
immediately. Another 300 TNCs should be ready to 
ship sometime in mid-September. When you call to 
order a TNC, you will be told whether your8 is to 
be part of the first batch or the second batch. 
The price of the TNC 2, including shipping, 
handling and credit-card charge8 will be $200.85. 
The TAPR phone number is 602-746-1166. 
Congratulations to the TNC-2 volunteers for 
completing a signif icant packet-radio project. 


From DRNET. 


IOWA ADDRESS CHANGE 


The Central Iowa Technical Society (CITS) has a 
new president and a new address. Contact CITS at: 


Richard E . Amundson, WA@FJS 
President CITS 

4621 SW 2nd St. 

Des Moines, IA 50315 


From DRNET. 


NOTES FROM GLB 


Ken Burton, N9CVV, reports the following 
developments at GLB. GLB will be coming out with 
two new models, the PKIL and the PK2. The PKIL 
will be the same as the the PKI, except that it 
will require just under 40 mA at 12 V. The PK2 is 
supposed to be entirely new, with some new 
features. They may also be offering a complete 
packet station: receiver, transmitter, amplifier 
and TNC all mounted in a 19" chassis. Simply add 
a power supply and you have a rack-mountable 
digipeater. Ken saw the prototype of a complete 
220-MHz network controller. It will run 9600 
bits/s and include transmitter, radio/modem and 
network control computer. GLB would 1 ike to hear 
what the amateur community wants designed into 
this controller. Write to Ed Jackson or Gil 
Boelke at: 


GLB Electronics 
151 Commerce Parkway 
Buffalo, NY 14224. 


Via DRNET. 
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MIRICOMPUTER ON PACKET. 


St. Louis Amateur Packet Radio (SLAPR), has 
acquired a DEC PDP-8 minicomputer. They would like 
to put the machine to some practical use on the 
local packet network. Because there are already 
several mailboxes on the St. Louis-area network, 
the club is interested in using the PDP-8 to store 
and distribute large files like Gateway. If you 
have any expertise that you might donate to this 
SLAPR project, contact 


Pete Eaton, WB9FLW 
35 Norspur, Route 4 
Edwardsville, IL 62025. 


VIA DRNET. 
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Mu Airy, Maryland, K3V¥PZ near Baltimore and 
N8FJB in Harper’s Ferry, West Virginia. Also, Bob 
Bruninga, WB4APR, has his Commodore VHF-to-30- 
meter gateway software converted to support 
commands and mail forwarding like a W@RLI system. 
So, the Baltimore/Washington network has the 
following major stations on 145.05 MHz: N8FJB, 
W3TMZ, K3VPZ and WB4APR-5. KS3Q scans 145.01, 
145.05 and 145.09 MHz. 


VIA EASTNET. 


NEWS FROM SOFTNET 


The Swedish SOFTNET User Group (SUG), in 
Linkoping, Sweden, has had its third workshop. 
SOFTNET is an experimental packet-radio system 
that uses distributed processing to provide 
network services. The SOFTNET nodes run at 100 
Kbits/s and are remotely programmed in a FORTH- 
like computer language. [For more background on 
SOFTNET, see Gateway Number 5.1 The following 
report on the SOFTNET workshop is from the 
newsletter SOFTNET News. 


The event was attended by about 50 SUG members and 
other participants from Sweden and Denmark. The 
first session started with introductory talks on 
the SOFTNET concept. These talks were followed by 
a hardware session which was dominated by Ingvars, 
SMSLRF, who presented the latest news on the 
Softnet radio transceiver [100-kbit/s modem]. 
While the transceiver has been available for about 
six months, minor modifications to improve the 
performance are continuously being made. During 
the lunch break, there were demonstrations of 
SOFTNET nodes and connections to several main- 
frame computers. 


The first session after lunch was devoted to 
SOFTNET programming. Fritte, SM5PSL, talked about 
activities of the SOFTNET Specification Group and 
presented some of the group’s proposals. Peter, 
SM5PQZ gave a talk on the implementation of an 
algorithm for distribution of system software 
through intelligent network flooding. 


An interesting talk on some of the commercially 
available packet radio systems was given by a 
member of the Swedish Telecommunications 
Administration. SOFTNET-like systems are of great 
interest to the Administration because they can 
solve data communication problems for fixed and 
temporary networks in difficult terrain. 


The next session was on packet radio in satellite 
systems. Sigge, SM5KUX, presented some of the 
plans on SWASAT, a Swedish Amateur Radio Satellite 
which is to carry advanced, high-speed packet- 
radio experiments. An interesting paper on the 
design of a doppler-shift adaptive modem for the 
IC-251/451 was also presented. 


The workshop concluded with a panel discussion 
chaired by Carl-Lennary, SM5ELD. Among the 
biggest issues of the discussion was the negative 
view of digital communications and packet radio 
taken by the HF Working Group of the IARU. The 
participants urged the spreading of more 
information to bring on a more positive attitude 
towards packet radio and experimental activities 
in general. 


VIA SOFTHET NEWS, SMSPSL. 


QSL TO HELP. DRNET. 


One of the constant sources of Gateway news 18 
DRNET, a computerized conference that is part of 
the New Jersey Institute of Technology’s, 
Electronic Information Exchange System (NJIT 
EIES). NJIT is interested in knowing how many 
people are served by DRNET. As Gateway readers, 
you all receive regular DRNET information. Please 
send a post card to 


CCCC @ NJIT 

Tom Moulton, W2VY 
323 King Blvd 
Newark, NJ 07102. 


Tom is the NJIT “sponsor” of DRNET, and he would 
like to be able to show that the 30 DRNET accounts 
are actually serving several thousand information- 
starved packeteers. He is also interested in how 
far messages from DRNET get distributed. On your 
card to Tom, tell him your name, call, location 
and packet setup, how you got this message, how 
often you receive messages that originate on 
DRNET, the name of your local packet group and the 
number of members in your group. The few minutes 
that you take to do this will help keep a vital 
source of information active. 


VIA DRNET. 


COHERENT DEMODULATION?. 


Fred Weidenhammer, W4SDL/2 writes that he is 
looking into the application of the techniques 
involved in coherent CW: (CCW) to HF packet 
demodulation. If you are interested in this, 
contact Fred and experiment. His address is 


322 Blacksmith Road 
Levittown, NY 11756. 


FROM W4SDL. 


600-Hz SHIFT FOR HF PACKET? 
While all of the stations using packet radio on HF 
are using 200-Hz shift at 300 bauds, there has 
been a lot of discussion of eventually using wider 
shifts. To start some public dialog and 
experimentation on this matter, here is a letter 
sent to Gateway. by Dr. Alan Chandler, K6RFK. 


"The 200-Hz shift that is becoming the defacto 
standard for 300-baud HF packet has a substantial 
deficiency when on an ionospheric path. Due to 
differential path length, both frequencies may be 
present simultaneously at the receiver and will 
generate a beat frequency. If the beat frequency 
is greater than the highest desired harmonic of 
the data, it may be filtered out and will not be a 
problem. If it is lower, the beat will be treated 
as data by the TU and will generate errors. In 
the case of 300-baud data, the fundamental is 150 
Hz, and the minimum 3rd harmonic should be passed. 
This gives a minimum shift of 450 Hz, and to allow 
economical filters, the minimum shift should be 
600 Hz, The TAPR and TAPR equivalent modems will 
receive 600 HZ shift without modification and they 
can easily be adjusted to transmit 690-Hz shift 
tones (1400 and 2000 Hz)." 


FROM AEA. 


performance left much to be desired...Only one QSO 
could*be managed. But that produced another 100 
points. On 145.01 MHz, where the packet action 
took place, the racket has to be heard to be 
believed. At times it sounded like one bong 
“brrrap’ as one packet followed another the 
instant the frequency was clear. It was a good 
demonstration of how packet allows a lot of 
stations to work on the same channel concurrently 
without QRM. 


"I ‘printed’ stations from all over Dallas and 
Tarrant counties. ..Many stations were extending 
their range by using the “digipeater” capability 
of the AX.25 packet protocol. 


“Field Day has shown that packet can add another 
dimension to traditional contest modes, as well as 
proving that you can take reasonably delicate home 
computer equipment and set it up in the field 
under adverse conditions and make it play...Packet 
radio is really out there, and it is beginning to 
‘intrude’ into areas of ham radio that formerly 
were the exclusive domain of CW or phone.” 


David Cheek, WASMWD, of the Texas Packet Radio 
Society, operated at the K5QHD Field Day site in 
Garland, Texas . 


"More than twenty three packet stations in the 
North Texas Section participated in the Field Day. 
About half were operating in the field, on 
emérgency power. At K5QHD in Garland, we made 20 
contacts, while two stations in Ft. Worth, made 23 
each. At least two other stations went over 15 
contacts, including W5CR in Athens. The best DX 
on two neters was with Salado on packet. Houston 
packet stations made lots of contacts with the 
help of the WD5GAZ digipeater. 


“We learned a few lessons: First, make sure all 
of your packet equipment is ready to operate in 
the field. Try to have 25 watts or more and an 
antenna at least 30 feet high. Second, finding a 
route to a station can be difficult, as is 
learning the call of the distant station you want 
to connect to. This can be handled by some limited 
beaconing, with each station continuously 
monitoring to gather new information about who is 
operating were. This can all also be’mapped out 
in advance. Third, excessive beacons can seriously 
slow down traffic on the frequency and should 
never be any more frequent than once every ten 
minutes. Beacons must include useful 
information, such as, ‘reach me through KC5LW-1l, 
WB5QNG and WA5MWD*. Fourth, the frequency must be 
kept as clear of other traffic as possible. This 
is no different from any other emergency 
operation. Finally, in a real emergency 
operation, two people are needed for each packet 
station. One will operate the transmitter while 
the other types traffic into a message computer. 
Only a station handling very little traffic -- 
less than ten ARRL radiograms per hour -- can be 
operated by one person.” 


There are two Field Day reports in the June/July 
issue of the NEPRA_PacketEar, newsletter of the 
New England-et Radio Association. John 
Langner,. WB208Z, operated with the Billerica 
(Massachusetts) Amateur Radio Society. They only 
made a few contacts, but did use packet radio to 
receive the official Field Day bulletin and send a 
message to the Section Manager. The packet 
operators explained packet to those who had never 


seen it and may have inducted a few new 
packeteers. 


Robert Gettys, NIBRM, was the sole packet operator 
at the Framingham (Massachusetts) Amateur Radio 
Association Field Day. Robert found that the lack 
of a second operator familiar with packet 
kept the station from being operated for the full 
contest period. He “found that you can’t teach 
someone who doesn’t understand the concepts of 
computers in general how to run a packet station 
and ‘search’ for possible contacts...or even 
enough [to conduct] a simple contact.” Robert 
made 21 contacts, and he was able to send and 
receive Field Day messages from the K1BC PBBS. 


Robert concludes that we need to find a recognized 
procedure for soliciting contacts (calling CQ), 
and he also notes that beacons and PBBSs 
contributed to severe channel congestion. His 
article ends with a few questions that the packet- 
radio and contesting communities should begin to 
think about: 


0 Should packet be used in contests at all? 

0 If so, in which contest(s)? 

0 What rules should be specified concerning 
digipeaters, beacons and frequencies? 

0 Should contacts with PBBS or stations under 
automatic control count? 


Robert feels that because Field Day is as much a 
test of emergency communication as it is a 
contest, packet radio is probably appropriate for 
Field Day. He is less sure about other contests. 


If you would like to put forth answers to any of 
Robert’s questions, send a letter to Gateway and 
to the members of the ARRL Contest Advisory 
Committee. 


CHAWED RAG, DRNET, PA-. 


EASTNET NOTES 


Gary Hoffmann, AK3P, in Hummelstown, Pennsylvania, 
has his W@RLI MailBox system running on 145.05 MHz 
as well as on 145.01 MHz. This allows users of 
the 145.05 MHz digipeater in York to access his 
system. Gary is using two radios in parallel to 
implement his dual-frequency node. He hopes to 
install a true multiport digipeater in the future. 
Gary is also planning to add 8n HF port to his 
MailBox, with antennas beamed toward Europe. 


Tom Clark, W3IWI, is also operating a MailBox with 
both 1435.05-MHz and 145.01-MHz inputs. Tom, 
however, is using the WORLI Gateway software to 
connect the two frequencies. To reduce the 
congestion that is beginning to bother everyone on 
145.01 MHz, all local users in Baltimore and 
Washington D.C. have been encouraged to use the 
145.05-MHz port. This helps keep 145.01 MHz open 
for EASTNET traffic entering and leaving the 
Washington area. The 145.05-MHz input is served 
by the W3GXT=-5 (Baltimore) and W3VD-5 
(Laurel/Columbia) digipeaters. The novel thing 
about this installation is that the radios for the 
two ports are combined using an RF-hybrid combiner 
to drive a single power amplifier and antenna. 


Tom sends these other notes: WORLI] MailBox systems 
are beginning to be used as personal mailboxes, 
Three new digipeaters on 145.05 MHz are W3TMZ in 


Garceway ecto 
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FIGHTING FIRES WITH PACKET RADIO 


This report on packet-radio communications during 
the Lexington and Santa Cruz Mountain (California) 
wildfire was filed by Ken Chong, WB6MLC, and 
edited by Hank Magnuski, KA6M. 


“During the afternoon of Sunday, July 7, reports 
were received by the local Amateur Radio Emergency 
Service (ARES) District Emergency Coordinator 
(DEC) that a new fire had been discovered in 
central Santa Clara County near the Lexington 
Reservoir, about 60 miles south of San Francisco. 


“Since the 4th of July the local ARES ‘Strike 
Team’ had been assembled and put on alert. This 
particular amateur radio team, unlike previous 
ones’ was equipped with a complete packet radio 
station. Late that Sunday, the team was called 
out to set up operations at the Alma Fire Station 
to handle communications concerning resources, 
tactical messages, fire updates and evacuation 


notices . 


“Throughout the day and further into the week, 
Fire Status Updates were sent out over packet when 
the voice nets were tied up. Once, when the phone 
lines were busy, packet radio got through to 
KA6YRK at another fire camp in San Luis Obispo, in 
Southern California. Many operators who had never 
operated packet before were literally baptized by 
fire! 


“On Tuesday, July 9, with the fire leaping rapidly 
from hill to hill, the main base camps and staging 
areas were moved to Vasona Park in Los Gatos. The 
towns of Los Gatos and Saratoga were severely 
threatened and many held their breath, hoping that 
evacuation orders would not be issued. At “Vasona 
Corn,” where the future amateur operations were to 
originate, a well-equipped van from the Palo Alto 
Red Cross was set up with packet equipment and an 
IBM PC programmed for use as a terminal. Two 
other radios for the voice nets were also in the 
van. Again, packet radio continued to function 
when the voice nets were busy. 


“One glaring problem, receiver desense, reared its 
ugly head during the operations. The local 
mountaintop digipeater was also malfunctioning, 
and two meter full-duplex repeaters were pressed 
into service. The retry rate increased so much 
because of the intermod products and desense that 
the packet technical crew transferred all digital 
traffic to full-duplex voice repeaters on 440 MHz. 
Finally, with the packet net secured on 440 MHz, 
all relays of fire updates to the different base 
camps continued without interference from the 
nearby two-meter radios. 


“Thanks to the hard work and contributions of 
many programmers, the packet operation at the main 
fire camp solved one more disturbing problem: The 
large pool of fresh operators had little or no 
experience with TNCs. most had barely heard of 
TAPR! The IBM PC was cleverly programmed to use 
its function keys to connect, disconnect and send 
various ‘canned’ messages. By Thursday, July 11, 
the whole operation was almost foolproof. At last 
an untrained operator could sit down and keep the 
net going. 


‘Packet radio did an outstanding job in proving to 
the fire officials its usefulness in an emergency 
and at the fire camps. The initial strike team of 
Frank Kibbish, WB6MRQ; Kit Blanke, WA6PWW and Bob 
Tarone, WA6ZBX and the packet setup crew of David 
Palmer, N6KL and WB6MLC were pleased with what 
evolved during the course of the emergency. When 
the smoke clears, a more detailed report will be 
filed. 


VIA DRNET 


ANOTHER FIRE REPORT. 


Paul Hansen, KA6UPD, sent in a newspaper article 
detailing some of his activities as a packet-radio 
operator assisting California firefighters. The 
article appeared on the front page of the July 14 
edition of the Thousand Oaks,’ California. ,News 
Chronicle, and it carried a photo of Paul and 
Jerry Boone, emergency coordinator for Ventura 
County ARES. The article gives some description 
of packet radio and the of work done by ARES 
members in the California disasters. Several 
paragraph6 are devoted to the reasons that Amateur 
Radio operator6 get involved in public service. 
Paul is quoted, saying, “We have an obligation to 
give public service to pay back for the right to 
use the frequency space we have.” Ray Volkmar, 
leader of the Conejo Valley Disaster Action Team, 
says that public service stems from “a love of our 
hobby and a love of being able to do something for 
someone else.” 


VIA KA6UPD. 


FIELD DAY REPORTS. 


It looks like a lot of stations took advantage of 
the 100-point packet-radio bonus this Field Day. 
The following reports detail some successes and 
some lessons learned. 


In The Chawed Rag, neweletter of the Richardson 
(Texas) Wireless Klub, George Baker, W5YR, reports 
that “unfortunately, the packet station 


TAPR PROJECT STATUS 


The TAPR TNC 2 is in the “final stages” of beta 
testing, with the hardware completely debugged and 
the final version of the software distributed to 
the dozen beta testers. The manual, one of the 
most demanding aspects of the project, is almost 
complete. It looks like initial estimates of 
“late summer or early fall” for availability of 
the first 300 TINCs were fairly accurate. The 
process of announcing the availability of the TNC 
2 and then taking orders for it will be tightly 
controlled. When TAPR is ready to take orders, 
electronic messages will be posted on DRNET and 
Compuserve HAMNET. Orders will be taken over the 
telephone, and only one order per person and one 
order per phone call will be accepted. No COD or 
purchase orders will be accepted. Once the first 
300 TNCs have sold out, there will be NO WAITING 
LIST. These rules will not be bent. 


The TAPR PC board for the K9NG 9600-bit/s modem is 
also just about through beta testing. Several of 
the boards in operation at beta sites. 


Ed. 
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This would require a control operator to examine 
each packet at a rate of 600 words per minute to 
keep up with the throughput capability of such a 
repeater. Furthermore, speeds higher than 1200 
words per minute are authorized, and technology is 
advancing toward higher and higher speeds.” 


After this, the comments address the common 
practice of using automatically controlled voice 
repeaters to pass third party traffic. In 
conclusion, the ARRL says: 


“We urge the Commission to modify its proposal so 
as not to impose a blanket prohibition of third- 
party traffic on stations operating under 
automatic control. We believe that the best way 
to achieve the goal of promoting the developing 
technologies in digital communications is to leave 
section 97.79 intact with the possible exception 
of clarifying section 97.79(d) by [adding the 
following text]: 


‘Participation means the origination, 
introduction or reintroduction of a 
communication into the amateur radio medium 
by a third party.’ 


“The proposed addition of this lagguage to section 
97.79(d) has the added benefit of clarifying that 
a control operator is required during operation of 
simplex autopatches. 


‘It is further urged that the proposed Rule 
sections 97.80(c) and 97.114(d) not be adopted, 
and that the Commission instead adopt the wording 
of 97.80, as originally proposed by the League, as 
follows: 


“97.80 Automatic Control of Digital 
Communications. 


‘Amateur Radio Stations may be operated under 
automatic control on frequencies above 30 MHz 
when utilizing digital communications 
pursuant to section 97.69, provided that the 
control functions include (i) adequate 
provision for detection of transmitter 
malfunction and discontinuance of transmitter 
operation in the event such malfunction is 
detected; (ii) devices installed and 
procedures implemented to ensure compliance 
with the rules when a duty control operator 
is not present at a control point of the 
stat ion. Upon notification by the Commission 
of improper operation of a station under 
automatic control, operation under automatic 
control shall be immediately discontinued 
until all deficiencies have been corrected. 


‘THEREFORE, the foregoing considered, the League 
recommends that the Commission extend automatic 
control to amateur digital communications above 30 
MHz. The League also requests that the proposed 
blanket prohibition of third-party traffic 
transmit ted on automatically-controlled stations 
not be adopted, and it urges that section 97 be 
amended by the adoption of section 97.80 as 
originally proposed by the League.” 


Ed. 


NORTHWEST NEWS 


The following update on the Northwest Amateur 
Packet Radio Association (NAPRA) comes from John 
Hayes, KD7UW, NAPRA’s Technical Vice President. 


“There is currently a network operating in Seattle 
on 145.010 MHz. In order to reduce the frequency 
of collisions and bring some organization to the 
frequency, use of the WN7ANK-5 digipeater is 
mandatory. Stations that can connect without the 
digipeater are encouraged to move to 145.050 MHz. 


“Northern Idaho and eastern Washington are now 
also served by a 145.010-MHz digipeater, N7BI-4 on 
Mica Peak. Again, the suggested simplex channel 
is 145.050 MHz. The packeteers responsible for 
the N7BI digipeater are affiliated with NAPRA and 
work with us on network coordination. To 
facilitate this, we hold an HF net on 3885 Khz, 
Thursday at 8 P.M. Pacific Time. 


“Doug Lux, WB6VAC, has been advocating the use of 
a ‘channel-busy’ signal to reduce the number of 
collisions at digipeater receivers. The packet 
repeater with a busy signal will, like a duplex 
repeater, use two frequencies. Whenever it is 
receiving a packet, it will transmit a busy signal 
on its transmit frequency. This signal will be 
recognized by stations using the repeater, and 
they will not transmit when they hear the busy 
signal. Once a packet has been completely 
received by the repeater, it will be regenerated 
(as in a digipeater) and retransmitted. The 
repeater with busy signal is addressed just like a 
digipeater. This addressing and the regeneration 
of packets before they are repeated may make the 
proposed system superior to a standard duplex 
repeater. WB6VAC will be experimenting to find 
out if the system works well. 


“We are working on expanding our network into 
Oregon, which is where we will meet WESTNET. A 
site in Longview, Washington, has been located, 
and we are working to put in a digipeater there. 
Longview ‘sees’ Portland, Oregon. The Utah Packet 
Radio Association (UPRA) and the Boise, Idaho, 
group are working to connect with us through the 
Pullman, Washington/Moscow, Idaho area. South- 
central Washington should be on the air later this 
summer. We also hope to work with VADCG to get a 
true Gateway into their 145.65-MHz network, which 
uses the V-2 protocol.” 


Via HAMNET. 


PACKET FOR THE COMMODORE 64 


The manufacturer of the PKT-1, Advanced 
Electronics Applications (AEA) will be announcing 
a packet-radio adapter for the C 64 sometime this 
fall. The adapter will plug into the C 64 like 
any other program cartridge, and it will provide 
AX.25 protocol software, a terminal emulator 
program and a modem. Transmission and reception 
of HDLC frames will be handled by hardware. To 
provide enhanced HF operation, AEA may use 
something other than the common EXAR IC modem. 
How much will it cost? Around $200, but the price 
has not been set yet. When will it be available? 
This fall, probably sometime in September. 


Via WB9OFLW, AEA. 


heard an ELT (outside of standard testing times). 
The system could then update DF information 
periodically or on command. Dave provides further 
detail6 of this idea in an article in the July 
issue of UPRA Connect. 


Via N7BHC. 


JAS-] UPDATE 


JAS-1, the amateur radio satellite built by the 
Japanese Amateur Satellite Corp. (JAMSAT), is 
complete, and should be launched in August of 
1986. Along with a linear transponder operating 
with a 2-meter uplink and a 70-cm downlink (mode 
J), JAS-1 will carry a "mode-JD" digital store- 
and-forward transponder. This transponder will 
operate like an orbiting packet bulletin-board 
system (PBBS), and ground stations will use AX.25 
TNCs and special modems to access the satellite. 


With two flight-ready satellites complete (a 
primary spacecraft and a backup), specifications 
of the mode-JD transponder are becoming available. 
The following detail6 come from the “Satellite 


Update” column in Amateur Radio Action, an 


Australian ham magazine. 


The transponder has four uplinks in the two-meter 
band and one downlink in the 70-cm band. The 
single downlink will be able to keep up with 
multiple uplinks because there will be frequent 
uplink collisions between ground stations that can 
not hear each other. The uplinks, on 145.85, 
145.87, 145.89 and 147.91 MHz will use 1200-bit/s, 
Manchester coded FM. The 435.91-MHz downlink, 
will use 1200-bit/s, non-return to zero inverted 
(NRZI), phase shift keying (PSK). 


While JAS-1 will probably be available to any 
appropriately-equipped ground station, it is 
likely that most stations will access the 
satellitethroughteleport stations. The use of 
central teleports has several advantages: users 
without satellite antennas will be able to take 
advantage of the satellite, time and money 
invested in building special modems will be 
reduced and contention for the satellite’s uplink 
channels will be minimized. 


With JAS-1 mode JD, the BUDAK experiment on Phase 
3-C and PACSAT all scheduled to be launched in the 
next year or 60, the horizons of packet radio will 
soon be greatly expanded. 


Via Amateur Radio Action. 


ARRL COMMENTS ON AUTOMATIC CONTROL 


The ARRL has filed comments on the FCC’s proposal 
to extend automatic control to all amateur 
operations above 29.5 MHz (RX-4879). Excerpt6 
from the ARRL comments follow: 


“The League reaffirms its proposal that automatic 
control of digital communications be permitted on 
all amateur frequencies above 30 MHz as outlined 
in its Petition. In the Notice [RM-4879], the 
Commission has built upon the League’s request, 
proposing that ‘any amateur station may be under 
automatic control, except where transmitting on 
frequencies below 29.5 MHz.’ In order to carry 
out its broader proposal, the Commission proposes 


to modify its Rule6 dealing with third-party 
traffic. 


“It is unfortunate that the Commission has 
introduced the issue of third-party traffic into 
this proceeding. It detracts from the primary 
purpose expressed in the Notice of keeping the 
amateur service abreast of technological 
developments such as computer-based message 
systems (CBMS) and other digital technologies. 
The proposed third-party Rule6 also impose 
unnecessary and onerous restrictions on the 
development and operation of digital 
communications networks. In fact, the proposal as 
presented in the Notice will not allow normal 
operation of CBMSs, which is contrary to one of 
the Commission’s goals as stated in the Notice. 
What is supposedly allowed radio amateurs by 
permitting automatic control is at the same time 
taken away by a proposed blanket prohibition from 
transmitting third-party traffic by automatically 
controlled stations as explained below.” 


The comments recall that the issue of third party 
traffic first came to importance in the late 
1970s, with the growing use and abuse of repeater 
autopatches. The casual use of autopatches lead 
the FCC to issue a news release in 1978 reading, 
in part, “Section 97.79(d) states that ‘the 
licensee of an Amateur station may permit any 
third party to participate in Amateur radio 
communication from his station, provided that a 
control operator is present and continuously 
monitors and supervises the radio communications 
to insure compliance with the rules.“’ The 
Commission in the same notice also stated that 
sect ion 97.79(d) clearly “prohibited autopatching 
and reverse autopatching through automatically 
controlled repeater stations and required a 
control operator to be on duty at all times during 
these operations.” 


From the ARRL comments: 


“What the Commission was seeking to guard against 
then was the origination and introduction of 
communications into the amateur radio medium by 
unlicensed individuals. 


“The commission misapplies this point in the 
[automatic control of digital communications] 
proposal, however, by seeking to prohibit ‘third 
party traffic from any amateur radio station under 
automatic control.’ A similar potential for abuse 
by unlicensed individuals in a digital amateur 
radio system exists only at the point where the 
third-party traffic is originated and introduced 
into the amateur radio medium. It is necessary to 
require a control operator at this stage only. 
This control operator will. guard against the 
potential abuse of amateur frequencies in a 
digital system just as effectively as the control 
operator on duty at a voice repeater station when 
an autopatch is accessed. To impose the 
additional burden of a control operator at every 
point along the digital system, be it at a CBMS 
site or at every packet ‘digipeater’ along the 
path to the message's destination is unnecessary. 
Such a requirement, in fact, would severely 
curtail the use of the developing digital 
technologies because the burden on control 
operators would be nearly impossible to shoulder. 
For example, messages on a packet radio repeater 
are received at a rate of 1200 words per minute, 
and retransmitted immediately at the same rate. 


Gateway 


The ARRL Packet-Radio Newsletter 


PACKET RADIO USED IN FIGHTING BRUSH FIRES. 


[The following is a report filed by Wally 
Linstruth, WA6JPR from an ongoing emergency 
operation. It is meant to convey the initial 
experiences of using a new, potentially formidable 
technology under emergency conditions.] 


Packet radio is playing an important role in 
aiding firefighters involved with the Wheeler 
Gorge forest fire that is still raging in the 
forests and brushlands east of Santa Barbara, CA. 
Bill Talanian, WIUUQ, President of the Santa 
Barbara Amateur Radio Club, reports that over 200 
messages have been cleared from the fire area in 
the last few days. The traffic consists of 
approximately 50 percent health and welfare and SO 
percent official fire department disaster- 
coordination messages for relay to the northern 
part of the state; 


The WESTNET digipeater system and the W6IXU 
mailbox are being used for much of the traffic. 
Traffic is also being cleared to NTS through Los 
Angeles area hams and WESTNET. 


The versatility and simplicity of the simplex 
digipeater was proven when the KA6SOX-1 Painted 
Cave digipeater was easily moved to La Cumbre peak 
for a better path into Pendola Camp, the main 
fire control point. A duplex repeater was also 
rapidly converted to a digipeater to enhance 
WESTNET coverage of the fire area. 


All is not roses, however, and we will have much 
more to report after the conclusion of the current 
activity. The problems uncovered during this 
emergency will provide serious food for thought 
for the packet-radio community. Two problems that 
have already been identified are: 


o Line-by-line entry is tedious and error prone. 
This is compounded by the fact that (at least 
here) the people involved in packet technology are 
not uniformly well trained in emergency traffic- 
handling procedures. Also, the well-trained ARES 
operators are not familiar with the details of TNC 
operation. This problem was handled by WIUUQ who 
received most outbound traffic at his home where 
the messages were reformatted using his word 
processor and retransmitted to their ultimate 
WESTNET destinations. 


o The California State emergency agencies have 
been convinced that packet is superior to means of 
sending messages. Because of this, state- 
purchased packet gear was being used in preference 
to ordinary traffic-handling methods, even though 
it was obvious to the control operators that 
traditional methods were operating at higher 
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efficiency. This situation got worse when the 
W61XU mailbox became congested because there is 
not yet a “data highway” from packet into NTS. 


We can draw one moral from these experiences, even 
before the final report has been filed: Make sure 
that you have a working packet-radio traffic- 
handling system before you “sell* packet to 
government authorities. 


Expect a more detailed report soon. 


From WA6JPR. 


PACKET AT THE JACKSON-HOLE HAMFEST 


The 1985 Wyoming-Idaho-Montana-Utah (WIMU) 
Hamfest, which will also be the ARRL Rocky 
Mountain Division Convention, has scheduled 
several packet-radio events. The hamfest will be 
held in Jackson Hole, Wyoming, August 2-4. Here 
is a tentative schedule of packet-radio 
happenings : 


Fri. 3 P.M. The Packet Radio hospitality room 
swings into action. 


Fri. 7P.M. All packeteers go to the Bar-J Ranch 


for a chuck-wagon dinner and Western variety 
show . 
Sat. 8 A.M. Packet talks begin, continuing 


until 10 am. The primary speaker will be Pete 
Eaton, WB9FLW. 


Jackson Hole, at the doorstep of Yellowstone 
National Park, is a great place to take the family 
if you want a combination vacation and hamfest. 
Plan your vacation so that you get both the best 
scenery and the most up to date packet radio 
information. 


From N7BHC. 


EMERGENCY LOCATION WITH PACKET RADIO. 


Dave Pederson, N7BHC, suggests a potential public- 
service use for high-altitude digipeaters. He 
suggest that we develop an emergency locator 
transmitter (ELT) direction finding (DF) receiver 
be interconnected with a packet station. 
Information from the DF receiver could be relayed 
via packet to search and rescue. authorities. The 
high-altitude sites occupied by many digipeaters 
would be quite good for receiving ELT beacons. 


A computer-controlled ELT DF system attached to ¢ 
TNC could send out an emergency beacon whenever it 


EASTNET AND WESTNET LINKED 


It’s not the “Golden Packet,” but there is now a 
reliable mail-forwarding link between EASTNET and 
WESTNET. Hank Oredson, WORLI, author of the 
popular MailBox software, provides the EASTNET end 
of the 20-meter link, and John Ejigenbrode, KD6SQ, 
provides the WESTNET end of the path. Messages 
usually take a day or so to make the cross-country 
trip. KD6SQ, in southern California, is not 
connected to the northern part of WESTNET, but 
messages into the Los Angeles area are reliably 
delivered. Harold Price, NK6K,AMSAT/VITA PACSAT 
manager, has regularly used the transcontinental 
link to communicate with the PACSAT memory group 
in Ottawa, Ontario. HF packet stations can be 
found exactly on 14.103 MHz, if you use LSB and a 
modem center frequency of 1700 Hz. 


Ed. 
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weather data with various meteorological sensors 
coordinated by a Commodore 64. The computer 
communicates with a TAPR TNC, and the weather data 
is periodically updated and transmitted. If you 
are interested in this project, Dennis and Philip 
have detailed plans, circuit diagrams and parts 
lists for the construction of the sensors and 
interface boards. To contact them, write 


Philip A. Johnson 
University of Minnesota 
116 Church Street SE 
Minneapolis, MN 55455. 


Further details on this amateur weather reporting 
system and the software and hardware that will 
make it possible will be printed in a future issue 
of the ARRL publication QEX. 


Via KAIDYZ. 


REPORT FROM ONTARIO. 


During the fall of 1984, a group of members of the 
Barrie Amateur Radio CLub with a budding interest 
in packet radio, decided to form a packet-radio 
study group. The goals of the group (called HEX 9 
because there were originally 9 members) were to 
study the material necessary for passing the 
Canadian digital license exam, to establish a 
local-area packet-radio network, to link with 
Ottawa and EASTNET and to promote packet radio in 
Canada. 


The results? A local-area network has been 
established, and 6 AX.25 stations are on the air. 
They are located at Orillia, Barrie, C.F.B. 
Borden, Alcona Beach and King City, Ontario. 
VE3LSR, in Edgar, is running a dedicated 
digipeater, and VE3HHW, in Alcona Beach, is 
running a packet-radio bulletin board on a TRS-80 
computer. The link to Ottawa will be available 
when arrangements are completed for a digipeater 
in KEssonville. 


HEX 9 has also planned a Packet Symposium, which 
will be held on September 21 at Georgian College 
in Barrie, ON. It is hoped that the speakers at 
the meeting will range considerably beyond the 
inspirational and background material is usually 
dealt with in the Amateur Radio press and at 
packet conferences. The planners of the Ontario 
Packet Symposium hope to cover some of the 
following topics: practical advice on how to enter 
packet radio; digipeating, theory and practice; 
packet radio and existing licensing requirements 
in Canada and the United States, including the 
reciprocal licensing privileges involved; possible 
changes in government regulations affecting packet 
radio; portable packet stations; gateways and 
protocols; packet voice; packet radio and public 
service; packet radio and satellites; scenarios 
for the future of packet radio and the bilingual 
and bicultural significance of amateur packet 
radio in Canada. 


For information on attending or speaking, contact: 
HEX 9 Group 
PO Box 151 
Orillia, ONTARIO 
CANADA L3V 633. 


From VE3NBN.. 


XEROX 820 AVAILABILITY 


If you are looking for a source of Xerox 820 
computers, consider 


BNF Enterprises 

119 Foster Street 

P.O. Box 3357 

Peabody, MA 01961-3357. 


They supply “as is” boards that they have made 
sure are in operating condition. For a rundown on 
the packet-radio applications of the 820, check 
Gateway issue 19. 


From W2KGV. 


MISSISSIPPI DIGITAL CLUB 


A group of Mississippi Amateur Radio operators 
interested in packet radio met late in May to form 
the Mississippi Amateur Radio Digital Association, 
MARDA. The purposes of MARDA are to represent 
Radio Amateurs in Mississippi who are interested 
in digital communications, to provide technical 
expertise in the promotion and advancement of 
amateur digital communications technology, to act 
as an information exchange and to provide 
communications for such state and local agencies 
as the Office of Emergency Preparedness, Civil 
Defense, police and fire departments. The MARDA 
network will include Hancock, Pearl River, 
Harrison, Stone, Jackson and George Counites. 


Those at the meeting agreed to support a band plan 
that has primary activity on 145.01 MHz and 
alternate channels on 145.03, 145.05, 145.07 and 
145.09 MHz. On the 220-MHz band, the group 
proposes to use 220.4, 220.72 and 220.78 MHz for 
“narrowband” activity, and 221.57 MHz for a 100 
kHz wide highspeed packet channel. 


MARDA 

c/o Joe Butler, K50S 
242 Woodland Circle 
Ocean Springs, KS 39564. 


Via W5CH. 


BAND OPENINGS 


The weekend of the ARRI. VHF contest, June 7 and 8, 
saw some good openings in the midwest. 

MailBox in Minneapolis, Minnesota, showed the 
following stations in its “just heard” log on 
Saturday, June 8: WD0CZI, KAONCR, WAOJFS-1, 
WDOEMR, WAOKGU, KCOOJ, WBOHRG, WBOGGL. Several of 
the stations heard «re from the Nebraska packet 
network in Fremont and Lincoln. Pat Snyder, 
WAOTTW, in Minneapolis, tried to «establish some 
connections to these "DX" stations, but had no 
success. Pat comments: “at least a few packets 
made their way to the 10,000 Lakes region. 
Propagation such as this seems to indicate that 
being on one packet channel, in this case 145.01 
MHz, can provide occasional DX activity.” The 
“just heard” log on the WORLI mailbox can be a 
good indication of band conditions, and time- 
stamped packet beacons (not on network 
frequencies) might prove to be a valuable aid to 
propagation study. 


Via WAOTTW. 


Marshall, WIFJI, transferred binary f iies using 
TAPR TNCs and a program called PMODEM. PMODEM was 
written by Skip Hansen, WB6YMH, and modified for 
the IBM PC by Tom Cain, WB80UE. It is written in 
c. If you are interested in more information, 
leave a message for K7PYK on one of the linked 
WORLI MailBoxes; Wes’station is a major HF link 
in the MailBox/GateWay system. 


Via DRNET and WA4FIB. 


KANTRONICS RECALL 


Kantronics has recalled all Packet Communicators 
with serial numbers below 49102. TNCs 

be replaced with newer units that have 
significantly enhanced hardware and software. The 
hardware changes result in reduced spurious 
radiations on 145.01 MHz. The early TNCs often 


frequency. Communicators with serial numbers 
If you have 


one of the recalled units, ship it to: 


1202 East 23rd Street 
Lawrence, KS 66044. 


Prom Kantronics. 


MICHIGAN PACKET 


operators in western Michigan are 
Radio Association (WMPRA). Write: 


WMPRA 

c/o Len Todd 

1819 Eloise Avenue 
Muskegon, MI 49444. 


Packet radio is also picking up steam in 
southeastern Michigan, and Eastern Packet Radio Of 
Michigan (EPROM), is coordinating activity in that 
part of the state. David Wang, N8BMA, has just 
established a MailBox in Detroit, and EPROM’s 
plans call for a 220-MHz network linking eastern 
Another of the 

club’s projects is "MNET" a multiuser bulletin- 
board system that will have both telephone and 
The packet network in 


southeastern Michigan, 147.555 


July. To contact EPROM, write to 
WB8TKL 
Monroe, MI 48161. 


Via Len Todd and KC80H. 


WISCONSIN CLUB 


The Wisconsin Amateur Packet Radio association 
(WAPR) has scheduled a meeting for all interested 
packet-radio operators to discuss the future of 
packet radio in Wisconsin. The meeting will take 
place at the South Milwaukee Hamfest on Saturday, 
July 13 at 11:00 A.M. in the Oak Creek VFW 
Building, near Milwaukee airport. For more 
information, contact: 


WAPR 

c/o David Boede, WD9FSH 
PO Box 1215 

Fon Du Lac, WI 54935. 


From WD9ESH. 


NYC DIGIPEATER 


There is now a digipeater in York City on the 
EASTNET frequency, 145.01 MHz. John Martin, 
WB2VIN, reports that he just got involved in 
packet and has placed a dedicated digipeater, 
WB2VIN-1, on the roof of a tall building in 
midtown Manhattan. The system seems to work well, 
with reliable connections to several major nodes 
EASTNET, 
WB2KMY, KG1O, WA2SNA, AI2Q, N2DSY. 


From WB2VIN. 


NORTH CAROLINA CONTACT 


K4CAV, 
Digital Communications Society, predominantly an 
RTTY club, is getting interested in packet radio. 


“fuel to the fire,” contact 


PDCS 

K4CAV 
4101 Summerglen Court 
Greensboro, NC 27406. 


Prom K4Cav. 


ATLANTA HAMFEST 


There will be a packet-radio forum and a computer 
forum at the Atlanta HamFestival, July 6 and 7. 
The HamFestival, sponsored by the Atlanta Radio 
Club, will be held in the Georgia World Congress 
Center, in Atlanta. If you want to meet some of 
the SOUTHNET packeteers, plan to attend. 


Via WA4RH. 
VETERAN'S PACKET NET. 


Roger Cooper, N3RC, is looking for volunteers to 
help establish a packet-radio network among U.S. 
This HF packet 
network would employ some rigs that are already in 
and there are funds 
available to purchase more rigs and packet 
If you would like to volunteer, 

telephone Roger at 202-389-5237. 


Via HAMNET. 


PACKET WEATHER NET UPDATE 


Although this information is a bit dated, packet 
operators should be interested to know that some 
progress has been made toward integrating amateur 
weather stations and amateur packet-radio 
stations. Phi lip Johnson and Dennis Moon, at the 
University of Minnesota School of Physics and 
Astronomy, demonstrated a prototype packet weather 
station last fall. They have been collecting 
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FLORIDA PACKETFEST 


The Florida Packetfest held June 14 and 15 has 
received rave reviews. The following report is 
from Jack, WA4FIB. 


“There were about 125 packeteers in attendance, 
from Florida, Georgia, Mississippi, Maryland, 
Illinois and a few other states. Gwyn Reedy, 
WIBEL, did a fine job of setting up the seminars, 
and the Gators at the University of Florida 
Amateur Radio club provided a great site for the 
convent ion. There were seminars on the TAPR TNC 2, 
9600-bit/s linking, the Gator-1 (and future Gator- 
2) networks, digital picture transmission (you 
should see the super pictures!), packet networking 
and the Xerox 820. There were often two seminars 
running concurrently, and some had to be repeated 
so that everyone could attend. Those who missed 
the gathering really missed a good, informative 
weekend. But fear not, there is already talk of 
another gathering within the next year.” 


Pete Eaton, WB9FLW, also attended the Packetfest, 
and suggests that other packet groups around the 
country try to hold their own regional packet 
convent ions. There are many hotbeds of packet 
activity where it would be easy to attract 100 or 
more interested people to a weekend of seminars 
and discussions. 


From WB4FIBand WBOFLW. 


QEX PACKET ARTICLES 


There are two items in the June issue of QEX: The 
ARRL Experimenters’ Exchange that might interest 
packeteers. First is a two-page article by Frank 
Roberts, VE3FA0, titled “Putting the Azden PCS 
3000 on Packet.” Frank believes that the Azden’s 
2-ms TR switching time makes the rig a good choice 
for packet radio, and he provides detailed 
information on how to correctly connect the 
necessary audio, PTT and squelch signals. The 
second article, by Robert Ball, WB8WGA, describes 
a simple, l-chip DC power modification for the 
TAPR TNC 1. 


Kd. 


PACKET INQST. TOO 


The July issue of QST will contain the first 
article in a two-part packet radio series by 
Harold Price, NK6K. The article, “What’s All This 
Racket About Packet?” answers the questions “what 
is packet?” and “what can it do?” It also 
provides some operating tips and a list of the 


frequencies used by packeteers in various parts of 
the U.S. If your friends have been asking you 
what the strange noise conirg from your radio is, 
have them read Harold’s article. The second 
article in the series, scheduled to be printed in 
the August issue of QST, provides a closer look at 
the TNC and the connections between the radio, the 
computer and the TNC. Congratulations to Harold 
for writing a fine, informative article. 


Ed. 


BINARY TRANSFER PROTOCOLS 


Jack Brindle, WA4SFIB, author of the 
MacPacket/TAPRterm software mentioned in Gateway 
issue 21, has also been at work on a protocol and 
software to solve the problem of sending binary 
files over packet links. A complete definition of 
Jack’s protocol will probably appear in the July 
issue of PSR Quarterly, but the outlines of it are 
presentedhere. Essentially, it is a transport 
(ISO RM level 4) and session (level 5) protocol 
with some elements of an application layer (level 
7). It includes several service classes and error 
detection and correction at the transport lager. 
The use of true sessions at the session layer will 
allow multiple connections from one terminal to 
numerous other stations, True multiple-connection 
capability will have to wait for improved link and 
network layer software, but terminals, 
incorporating Jack’s protocol will be able to 
perform several functions simultaneously even with 
the current TNC link layer. This means that you 
could transfer a file and hold a conversation 
simultaneously, 


Jack is not the only person experimenting with 
binary-file transfer protocols. A message on 
CompuServe IAMNET from Mark Matthews, WA6L20, 
provides a detailed look at a simple file-transfer 
mechanism for packet radio. Mark’s protocol can 
transfer files of any length, using almost any 
file-name format. Either the station wishing to 
receive a file or the station wishing to transmit 
a file can initiate a transfer, and there is a 
flexible error-reporting system. Mark uses some 
six-character attention sequences to synchronize 
the file transfer, and transmits the name and 
length of the file in a specially-formatted 
header. The transfer protocol assumes that the 
AX.25 (TM pending) link will deliver error-free, 
correctly ordered data to the receiving station, 
but there is a “crash timer” and an acknowledgment 
sequence to detect link failure. 


In yet a third file-transfr: project, Wes Morris, 
K7PYK, reports that on June 16, he and Art 


EASTNET-HF NET 


Participation in the EASTNET 75-meter SSB net has 
dropped to only two or three stations. To try to 
generate more interest, the unofficial net control 
station has decided to move the net to Thursday 
night, 9:00 P.M. EDT. The frequency remains 3.855 
MHz. If you are interested in the growth and 
design of EASTNET, please check into the net. If 
you are new to packet radio and want some 
questions answered, turn on your HF rig and ask 
the assembled “experts.” 


Via WB2RKMY. 


TAPR CLOSES HF BET. 


Poor propagation and lack of net-control stations 
have caused TAPR to discontinue its 15= and 20- 
meter HF nets. 


Via PSR. 
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CONNECTICUT. PACKET CLUB 


Connecticut now has its own packet radio club, the 
Southern New England Association of Packeteers 
(SNAP). The club will assist the development and 
organization of packet radio in Connecticut and 
strive to integrate the Connecticut segment of 
EASTNET into NTS. There have already been two 
meetings of SNAP, although the election of 
officers and the ratififcation of constitution and 
bylaws have been delayed until the July 2 meeting. 
The club will meet on the first Tuesday of every 
month, at 7:30 P.M. in the ARRL Headquarters in 
Newington, Connect icut. SNAP will hold a Z-meter 
FM net, Wednesdays at 9:30 P.M. on 147.75/.15 MHz. 


From KE3Z. 


CONNECT INDICATOR 


If you are wondering what to do with the signals 
available from the parallel port of your TAPR or 
Heath TNC, the Maxtec "KON-D-KON INDICATOR” may be 
for you. KON-D-KON is a small (1.5- X 1.5-inch) 
circuit board that connects to your TNC and a 
speaker and sounds a short tone when someone 
connects to you. When KON-D-HON is connected, the 
“spare” LED on the TNC indicates connect status. 
KON-D-KON is available as a bare PC board, a 
complete kit or assembled and tested, from: 


Maxtec Writing 
3721 Spring Valley No. 111 
Addison, TX 75234. 


Max Adams, W5PFG, maker of KON-D-KON, reports that 
the gadget helped him work W4WEB near Panama City, 
Florida. Max was not at his terminal when W4WEB 
connected, but the KON-D-KON alerted him and he 
was able to complete the 600-mile contact. 


From W5PFG. 


NTS, PACKET AND _ASSISTANT TECHNICAL COORDINATORS 


In the Eastern Massachusetts section, packet radio 
was united with the National Traffic System (NTS) 
to help find volunteers for the new ARRL Assistant 
Technical Coordinator (ATC) appointments. Luck 
Hurder, KY1T, and Mort Cohan, KAIIU, used a list 
of ARRL members in the EMASS section to address 
several hundred radiograms. The radiograms were 
stored on the K1BC PBBS, which is dedicated to 
traffic handling, and NTS members with packet 
stations either delivered the messages or relayed 
them to the NTS Section net. The radiograms were 
delivered quickly and resulted in responses from 
more than 30 qualified candidates. The support of 
NTS by packet networks is important, and we are 
interested in hearing from people who are 
developing connections between the two 
communications systems. 


Via KYIT. 


BINARY FILE TRANSFERS 


Many packeteers want to transfer binary files 
using packet radio, and this is one of the 
“services” that will be demanded of future packet 
networks. Several recent messages on CompuServe 
HAMNET discussed attempts to use telephone data- 


transfer protocols like XMODEM and KERMIT to 
transfer data over packet-radio links. The delays 
introduced by the packet channel make these 
timing-sensitive protocols nearly useless. The 
packet-radio community needs to agree on a simple 
but expandable protocol for binary transfers. The 
protocol need not detect or correct errors, since 
the AX.25 link will take care of these things. 
The protocol must provide a means for the sending 
station to find out when the receiving station is 
ready, and it must. provide some data-transparent 
mechanism for detecting the end of the transfer 
(some kind of byte counting mechanism, perhaps). 
If you are working on such a protocol, it is time 
that you made it public. Consider writing an 
article for one of the packet radio newsletters. 


Via HAMNET. 


220-MHZ EXPERIMENT 


Norm Sternberg, W2JUP, is running a packet beacon 
on 221.02 MHz from midnight to 8 A.M., EDT.  Trtie 
beacon runs 25 watts to an omnidirectional antenna 
in Farmingville, Long Island (grid square FN30). 
This experiment should provide an indication of 
the propagation that will be faced by the EASTNET 
stations planning to install 220-MHz, 9600-bit/s 
links. Norm would like anybody who hears the 
beacon to report to him at 516-698-8818, or on his 
BBS at 516-726-2208. 


Via HAMNET. 


MACINTOSH PACKET _PREPROCESSOR 


If you have a Macintosh computer and a TAPR- 
compatible TNC, you will be excited by the 
announcement of the MacPacket/TAPRterm. This 
“front-end processor” turns your Macintosh and TNC 
into a ccmplete computer communications system. 
It features a split-screen display, pull-down 
menus containing all TNC commands and parameters, 
file uploading and downloading, and a routing file 
(so that you don’t have to remember the calls of 
every digipeater to connect to someone>. The 
program makes extensive use of the famous 
Macintosh user interface to help you make your 
packet station more “friendly.” The split-screen 
display ends the problems of deciding who typed 
which characters. TNC parameters may be modified 
by “pulling down” one of the TAPRterm menus. To 
connect to another station, you simply select 
“Connect” from the command window, type the call 
sign of the station that you want to connect to 
and activate the automatic routing system. 
Uploading and downloading of text files and 
printing of received data are currently supported. 
Binary data transfer will be available shortly. 
The software is available from: 


Br incomm Techno logy 
19451 Gulf Blvd. #503 
Indian Rocks Beach, FL 33535. 


The $389.95 price includes all updates for one 
year 


Via HAMNET, WA4FIB. 


communications, He suggests that packet-radio 
clubs carry out their own emergency drills before 
trying to impress public-safety agencies with 
packet radio. 


For those who live in the northeast, the New 
England Packet Radio Association (NEPRA) prints 
the Packetear. This is another newsletter with 
items of both local and general significance. 

As packet radio becomes more and more popular and 
commercial equipment becomes widespread, clubs 
that are not dedicated to digital communications 
are getting interested in packet. This is 
reflected in numerous newsletters that we receive 
from Amateur Radio clubs throughout the country. 
The newsletter of the Mid-Atlantic Amateur Radio 
Club reports that the club will support a 
digipeater and a packet bulletin-board system 
(PBBS) in the near future. The Ramapo Mountain 
Amateur Radio Club (New Jersey) already supports 
WA2SNA, a major digipeater in EASTNET. The most 
recent issue of their journal contains an overview 
of packet in the U.S., a map of the major links in 
EASTNET and a report on high-speed linking 
efforts. On the west coast, the Boeing Employees’ 
Amateur Radio Society (BEARS) digital 
communications committee is assembling a digital 
position at the club’s station. The position will 
include packet radio, of course. The Palo Alto 
Amateur Radio Association newsletter, PAARA 
Graphs, is filled with packet-radio information, 
including a WESTNET map and some messages captured 
from the local PBBS. 


These items are presented to show that packet 
radio is spreading, and that both special-interest 
and general-interest Amateur Radio Clubs are 
talking about digital communications. If your 
local club isn’t on packet yet, consider writing 
an article for their newsletter. Editors are 
always looking for items to print. If your packet- 
radio club publishes a newsletter, please be sure 
to put Gateway on the mailing list. 


From Various Newsletters. 


CONSTRUCTION CLASS 


Bob McCormick, KAIKPH, has come up with an 
interesting way to get members of the Hampden 
County Radio Association onto packet radio. Bob 
is going to hold a “Let’s Build a TNC” class 
during which club members will build Heath HD-4040 
TNCs and learn to use them. He hopes that this 
will familiarize the attendees with good 
construction techniques and give them some 
guidance during the “now that its built, what do I 
do with it?” phase. This sounds like something 
that a club might plan in the summer and execute 
in the fall, giving everyone something to look 
forward to. (Bob should also be congratulated for 
his two-part introduction to packet that was 
printed in recent issues of World Radio.) 


Via HCRA Zero Beat. 


CABINETS FOR TAPB FROM HEATH 


If you didn’t get a custom cabinet for your TAPR 
TNC 1, and you’ve still got your TNC mounted on 
plywood or sitting on the bench, Heath has come 
the rescue. A call to Heath’s parts department 
confirmed that they have put together a package of 


parts that contains everything that you need to 
put your TAPR TNC 1 into the brown, low--profile 
cabinet that Heath’s HD-4040 comes in. The parts 
included are the chassis, cabinet top, low-profile 
transformer, line cord, power switch, LEDs and 
hardware. Total price for the parts is just under 
$40, and Heath has everything in stock but the 
cabinet tops. Since TAPR has no more cabinets, 
this is probably the best deal going for TNC 1 
owners who want cabinets. To order, call Heath at 
616-982-3571. 


From NICB and Heath. 


PACKET AND THE IEEE 


May was a good month for packet radio in the 
professional electronics press. The Institute of 
Electrical and Electronics Engineers (IEEE) is a 
professional organization that prints many 
publications, both general and specialized. In 
the May issue of IEEE Spectrum, the magazine 
received by all IEEE members, there is an article 
titled “The High-tech Hobbyhorse,” discussing how 
“personal computers and computer-based systems are 
turning two of the oldest hobbies in the United 
States -- amateur radio and model railroading -- 
into high-tech pastimes.” Two packeteers, Harold 
Price, NK6K, and Terry Fox, WB4JFI, were 
interviewed for the article, and packet is 
discussed extensively under the heading ‘A network 
node in your home?” There is also a photograph of 
Harold’s station; a TAPR TNC and several computers 
show clearly. The technical IEEE Journal on 
Selected Areas in Communications, in a special 
issue devoted to communications for personal 
computers, carried article called “Packet Radio 
in the Amateur Service.” This article was written 
by Phil Karn, KA9Q, Harold Price, NK6K, and Bob 
Diersing, N5AHD. Congratulations to all involved 
for pointing out to the professional community 
that Amateur Radio is still state of the art. 


Ed. 


ITU FASCICLES AVAILABLE 


What is a "fascicle” and why is it in Gateway? 
Well, Webster’s gives us the interesting 
definition "1 a: an inflorescence consisting of a 
compacted cyme less capitate than a glomerule” and 
the more relevant “2: one of the divisions of a4 
book published in parts.” In this case, we are 
talking about some fascicles published by the 
International Telephone and Telegraph Consultive 
Committee (CCITT) detailing their R, S, and U 
series Recommendations. Volume VII -_Fascicle 
VII.1, covers telegraph transmission (R series) 
and telegraph services and terminal equipment (S$ 
series). Volume VII ~ Fascicule VII.2 is the U 
series Recommendations for Telegraph Switching, 
including telex internetworking. The two 
fascicles, or “fascicules” are available for 34 
and 31 Swiss francs, respectively. Write to: 


International Telecommunication Union 
General Secretariat, Sales Service 
Place des Nations 

CH-1211 Geneva 20 

SWITZERLAND. 


Via W4RI. 
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GATEWAY DELAY 


This issue of Gateway is the one that you expected 
on June 4. It was postponed until June 11 because 
the editor was on vacation. Gateway will now 
resume its schedule of an issue every two weeks; 
issue 22 will be printed on June 25, issue 23 on 
July 9, and so on. This one-week shift of the 
schedule also helps us with another problem: 
summer is a slow period for Amateur Radio, and 
there isn’t as much news as we would like. Please 
send items for Gateway, either through the mail to 
ARRL Headquarters , via CompuServe (our user number 
is 75105,737), or via DRNET (you may have a DRNET 
member in your area>. We are especially 
interested in reports of Field Day packet 
activity. 


Jeff Ward, Editor. 


INTERNATIONAL PACKET NEWSLETTER 


We have received a “beta test” issue of 


PacketWorld - - International Journal of Packet 


Radio. The newsletter, published by anew club 
called Packet Telecommunications International, 
will address “packet radio for hams, computer 
enthusiasts and businesses.” PacketWorld will 
come out every two months, and a one-year, six- 
issue subscription is $10. The first issue, due 
out in July, will include articles on protocols, 
regional networks, hardware and software, mobile 
data terminals and bulletin boards. Packet 
Telecommunications International meets regularly 
in Santa Rosa, California. To subscribe or 
contribute to PacketWorld, contact: 


PTI West 
520 Mendocino Ave, Ste 340 
Santa Rosa, CA 95401. 


From PacketWorld and KA6ATN. 


PSR GOES QUARTERLY 


The_Packet Status_Register (PSR), newsletter of 
the Tucson Amateur Packet Radio Corp. (TAPR) will 
become the PSR Quarterly in July. The folks at 
TAPR believe that the_PSR’s role as a carrier of 
timely operational and organizational news is 
being filled by other publications and that what 
the packet-radio community needs is a technical 
journal carying items of lasting significance. 
The new_PSR Quarterly, scheduled to be published 
every July, October, January and April, will fill 
this need. 
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Gwyn Reedy, WIBEL, will be the editor of the new 
publication. Judging by the quality of Gwyn’s 
editing of the FADCA>BEACON, PSR Quarterly will be 
an attractive, informative publication. Remember, 
however, that a successful technical publication 
needs more than a skilled editor; it needs good 
technical articles. If you want to submit an 
article for the July issue of the PSR Quarterly, 
it should reach Gwyn by June 25. Send articles 
to: 


Gwyn Reedy, WIBEL 
Editor... PSR Quarterly 
812 Childers Loop 
Brandon, FL 33511. 


Via PSB and DRNET. 


NEWSLETTERS 


We receive several packet-radio news’. 2tters, some 
intended for local distribution and 3ome national 
in scope. Without reprinting entire newsletters, 
we would like to present some of the highlights of 
those received recently. 


FADCA>BEACON is the journal of the Florida Amateur 
Digital Communications Association (FADCA), but 
this large newsletter carries articles that are 
interesting for all packeteers. For example, the 
May issue of FADCA>BEACON contains several 
columns, including one for beginners, and features 
on the TAPR TNC 2, the Kantronics TNC, 9600-bit/s 
linking, a double-density disk controller for the 
Xerox 820 and the proposed TAPR network 
controller. There is also an index to all 
previous FADCA>BEACON articles. The layout and 
artwork in this newsletter, done by Brad and 
Cheryl Voss, make the FADCA>BEACOr a pleasure to 
read. Back issues of FADCA>BEACOK are available 
for a reasonable price. For more information on 
FADCA and its newsletter, write FADCA, c/o Gwyn 
Reedy, WIBEL, at the address in the "PSR GOES 
QUARTERLY” item in this issue of Gateway. 


UPRA CONNECT is published by the Utah Packet Radio 
Association (UPRA). The May issue of the UPRA 
CONNECT is 11 pages long, and it provides local 
news and reprints from other newsletters. Dave 
Pedersen, N7BHC, reports that the Salt Lake City 
group hopes to to establish links to Boise, Idaho, 
Anaconda, Montana, and Grand Junction, Colorado 
before this winter. UPRA has prepared an 
information package that it will send to groups 
interested in helping establish these 
intermountain links. In another UPRA CONNECT 
article, Steve Peterson, KI7L, discusses the 
important topic of Amateur Radio emergency 


have the date of the transaction available and 
information on the method of payment. If you call 
after hours, you will get the answering machine; 
Please leave a number where you can be reached 
during the day. 


Please do not call about any of the following 
items: 


Orders for TNC-2 

New TNC-1 kit or cabinet orders 
9600-bit/s modems 

TNC software or hardware questions 


Both TNC-2 and the 9600-bit/s modem boards are in 
beta test now. TAPR will begin taking orders when 
they are available. 


The TAPR phone number is (602) 746-1166. 


From NK6K. 
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SIGHTLESS HAM ON PACKET RADIO 
April 25, 1985 marked an important event for the 
Rochester packet-radio fraternity. 1985 has seen 
rapid growth of packet in the Rochester area, but 
the highlight has to be the appearance on packet 
of Walt Keleher, KA2ASL. What’s so unusual? Walt 
is blind. 


Operating on voice or CW without sight presents 
some challenge, but think about operating on 
packet radio without your sight. Sending is not a 
big problem, since Walt can touch type, but 
receiving is another story. Walt has an Apple Ile 
computer, an Echo voice synthesizer and a 
specially developed terminal program. This 
terminal program unites the computer/terminal and 
the text-to-speech functions of the synthesizer or 
“talker.” Whatever appears on the screen of the 
computer is “read” by the talker, in nearly 
perfect speech. If pronunciation errors are made, 
Walt can back up to get a repeat or to have the 
unit spell out the unknown word or phrase. 


On the evening of April 25, Dave Denz, N2DWL, and 
Mark Winrock, both members of the Rochester packet 
group, went to Walt’s home and set up his TNC and 
radio. After a short period of instruction and 
coaching, the big moment arrived. The equipment 
worked perfectly. Walt worked WB2NBU, K2YNW and 
W2DUC in rapid succession. While Walt was taking 
his time learning about packet operation, the rest 
of the gang was taking turns sending to him. Walt 
reports that we are perfect copy, but all seem to 
have a Swedish accent (a common trait of text-to- 
voice processors). 


It was exciting evening, introducing Walt to 
packet radio and helping willpower overcome a 
great barrier. 


From W2DUC. 


CORTACTS IN THE SOUTH 


At a recent packet-radio forum at the Baton Rouge, 
Louisiana hamfest, several amateurs from Louisiana 
and Mississippi expressed the need for better 
communications among the scattered centers of 
packet radio in the southern U.S. If you are 
lncerested in helping connect the western reaches 
of "SOUTHNET," write: 


Ken Shutt, K5GUU 
12433 Archery Dr. 
Baton Rouge, LA 70815 


or 


Alan Clark, WD5IKD 
2325 Milam Street 
Pearl, MS 39208. 


In areas where packet stations are few and far 
between, it is important that those who are on the 
air or interested in getting started can get in 
touch with others who’ve been bitten by the packet 
bug. 


Via WD5IKD, K5GUU. 


INTERMOUNTAIN REPORT 


Dave Pedersen, N7BHC, of the Utah Packet. Radio 
Association (UPRA), recently gave a packet-radio 
introduction and demonstration to more than thirty 
people in Boise, Idaho. There are several packet 
stations under construction in Boise. Dave, 
located in Salt Lake City, Utah, reports that he 
has been able to make a 300-mile direct connection 
with Jeff Bishop, W7ID, in Boise. Unfortunately, 
the path is not quite solid on 2-meter FM. Dave 
and Jeff regularly hold Z-meter SSB skeds, and 
they hope to try some SSB packet (real FSK instead 
of AFSK on FM) soon. A digipeater link between 
Salt Lake City and Boise should be completed this 
summer. 


From N7BAC. 


HF PACKET 


If your VHF packet network is getting a bit 
crowded or you just want to try out another facet 
of packet radio, connect your TNC to your HF rig 
and give HF packet a try. HF packet stations 
transmit at 300 bauds, using a 200-Hz shift. 
While some stations are using Bell 103 modems 
modified to transmit and receive on one set of 
tones (simplex), any 200-Hz shift modem can be 
used. If your transmit tones are the same as your 
receive tones, just tune in another station and 
you’re on your way. Packet-radio employs NRZI 
encoding, so which sideband you use is not 
important. Most of the HF packet activity is on 
30 and 20 meters, with 10.147 MHz and 14.102 MHz 
the popular frequencies. The following stations 
are running the WORLI Gateway software on HF 
packet: KIOQ, Ames, Iowa; N4CI, Conyers, Georgia; 
KF4JF, Hahira, Georgia; K7PYK, Scottsdale, 
Arizona; WA4SZK, Florence, South Carolina; WORLI, 
Westport, Massachusetts; KD6SQ, Cucamonga, 
California; KAIPN-1, Nashua, New Hampshire. Hank 
Oredson, WORLI, reports that a new Gateway station 
comes on the air each week. So, slow down your 
TNC and narrow your modem to try HF packet. 


Via WORLI. 


TAPB "OLD BUSINESS DAYS" 


From Monday, May 20, through Friday, May 31, 9:00 
AM until 5:30 PM PST, TAPR will double its office 
staff and disconnect the telephone recorder. 
During this time they will have a human answering 
the phone, and they will be returning the backlog 
of calls that has built up. 


What exactly is “Old Business Days”? It’s a 
marathon session during which TAPR hopes to clear 
out the last loose ends of the TNC-1 product line. 
Call if you have any outstanding business with 
TAPR regarding any of the following items: 


TNC-1 Kits 

TNC-1 cabinet kits. 

Beta Upgrade kits. 

Outstanding spare parts orders. 


Also take this opportunity to order spare or 
replacement parts for TNC-l. 


If you are calling about a backlog order, please 


station setup, north and south: KA6SOX, W1UUQ, 
WA6CFM, WD6FPY, WB6DAO, W6IXU, N6OBGW, N6CXB, NK6K, 
AJ6T, WB6UCK, N6ZH, NG6P, K6QIF, KB6JM, WB6HHV, 
W6AMT. There were 6 packet stations directly 
involved with traffic handling and 10 digipeaters 
involved in the network. 


From NK6K. 


IBM PC PACKET ADAPTER 


Jack Botner, VE3LNY, whose article "A Packet Radio 
Adapter for the IBM PC" appeared in the January 
1985 issue of QEX, has received many inquiries 
concerning software for his 8273 HDLC adapter. He 
reports that an implementation of the VADCG 
protocol is available from the Hamilton Area 
Packet Network (HAPN). The protocol software is 
written in assembler, and the support programs are 
written in C. To receive the software, send $15, 
a diskette and a disk mailer to: 


Jack Botner, VE3LNY 

35 Wynford Hights Circle #1708 
Don Mills, Ontario 

CANADA M3C ILI] 


Software supporting the AX.25 protocol is not yet 
available for Jack's adapter. HAPN would like to 
hear from anyone interested in developing AX.25 
software for the interface. 


From VE3LNY. 


COLLECTION OF PACKET PAPERS 


If you have been reading any of the books 
recommended in_Gateway, you have probably noticed 
that a few "classic" papers on packet switching 
are referred to over and over. Tutorial 
Principles of Communication and Networking 
Protocols, edited by Simon S. Lam is a 
comprehensive collection that includes many of 
these essential papers on digital communications. 
The papers cover link protocols, multiple access 
methods, local-area networks, resource allocation 
in networks, network and internet services, and 
protocol verification. The collection is 
published by The Institute of Electrical and 
Electronics Engineers (IEEE), and it is ISBN 0- 
8186-0582-o0. 


Via KA9Q. 


PACSAT FUNDING 


As reported in Gateway 15, the Radio Amateur 
Satellite Corporation (AMSAT) and The Volunteers 
in Technical Assistance (VITA), have completed 
engineering specifications for PACSAT, a proposed 
store-and-forward, packet-radio satellite. In the 
two months since the design and strategy meeting, 
no sources of the necessary funding have been 
identified. Recently, VITA was granted several 
thousand dollars to retain a professional fund 
raiser for the PACSAT project. While this should 
help, it is still important that amateurs assist 
by identifying potential sources of major 
contributions. Also, as in past amateur-satellite 
projects, individual and club donations to the 
PACSAT fund will be necessary. If you can help, 
contact: 


VITA 

1815 N.Lynn 

Arlington, VA 22209 

Attn: Gary Garriott, PACSAT Project Manager 


Ed. 


JAS-1 PACKET INTERFACE 


The April issue of the Japanese magazine CQ Ham 
Radio has an article by JAIANG, based on material 
from Miki Nakayama, JRISWB, describing the user 
interface to the packet mailbox that will fly on 
the JAS-1 satellite. It shows a sample message 
from W3IWI to JRISWB as it would be received at 
JRISWB and then a reply. The dialog shown in the 
Magazine is reconstructed below: 


(Legend in left-hand column: 
$: JAS-1 ==> User 
%: User ==> JAS-1 
&: TNC <==> User) 


& cmd:CONNECT JAS-1 
& *** CONNECTED to JAS-1 


$ Hello JRISWB de JAS~-1 
$ Your last access was on 85/01/11 at 1922 UTC 


$ NO. DATE FROM TO SUBJECT LINES 
$ 15 01/28 W3IWI JRISWB AX.25 SOFTWARE 3 

$ Command ? 

% READ 15 


$ Posted: Mon 85/01/28 From: W3IWI 

$ To: JRISWB 

$ Subj: AX.25 SOFTWARE 

$ I have the disks ready to mail to you and the 
$ packet is all sealed. $ Tom 


$ COMMAND ? 
% WRITE W3IWI 
$ Subject: 


% Re: AX.25 SOFT. 
$ Text: 


% Tom, I'm looking forward to receiving the 
& packet. 

" 73's Miki 

Jo « 


$ Message from JRISWB to W3IWI saved as #18 
$ COMMAND? 


% BYE 
& *** DISCONNECTED 


This protocol is a combination of features of the 
WORLI MailBox (JRISWB has a Xerox 820 and is 
running the MailBox) and of TeleMail (the 
message in the example was sent via TeleMail). 


JAS-1 is scheduled for launch in 1986. Uplinks 
will be on 2 meters (145.85, .87, .89, .91 MHz) 
with a single downlink on 70 cm (435.91 MHz) using 
1200 bauds, phase-shift keyed (PSK). 


From W3IWI. 
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CALIFORNIA PACKETEERS PARTICIPATE IN “QUAKE '85" 


A simulated earthquake occurred on April 16 in 
southern California. The simulated quake was 8.2 
on the Richter Scale. A quake of this size would 
cause a great deal of destruction and would most 
likely result in the immediate loss of most 
communications over a large area for several 
hours. As is the case for most large-scale 
exercises of this type, amateur radio played a 
part. This year, for the first time, packet radio 
made major contributions. 


The goal was an ambitious one: to move traffic 
from the State Off ice of Emergency Services (OES) 
communications trailer in Los Alamitos to the OES 
off ice in Sacramento, 400 miles to the north, 
using VHF. This required the use of seven 
digipeater6. We learned several things during the 
exercise: First, it is possible to move a large 
amount of traffic that distance through that many 
digipeaters, and second, it wasn’t possible to do 
it in the way we had originally intended. 


We also had several unplanned events preceding and 
during the exercise which added to the simulated 
emergencies. First, California is blessed with a 
geography that provides 4000 to 8000 foot 
mountains and over-water paths. The length of 
most of the paths used in the network (called 
WESTNET) is 90 miles, with one path of 120 miles 
and another close to 200 miles. The longer paths 
require over-water ducts, which are in place for 
much of the year, Two days before the exercise, a 
weather pattern went through that destroyed the 
ducts, which didn’t return for several days. 


Also, three digipeaters failed the day before the 
exercise. This was the largest network failure 
experienced before or since. The systems were 
repaired in hours, and portable systems were 
readied. During the exercise, one system was 
driven to a mountain top to supply backup for the 
lost duct, and another system was “car mobile” at 
the OES site, ready to be driven or helicoptered 
should the need arise. 


In addition to the amateur-owned equipment in 
place, the OES had previously purchased several 
TNCs; one was installed in their communications 
van in Los Alamitos and another in their office in 
Sacramento. A third was at an intermediate 
digipeater site in northern California. To make a 
long story short, soon after the exercise began, 
we established communications with Sacramento. 
Unfortunately, it was lost soon after, because of 
a flaky path at the far northern end. We didn’t 
find this out until much later, of course. We 
interspersed an hour of attempted reconnects up 
north with passing traffic around the southern 
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California area - San Diego, Santa Barbara, 
Glendale and others. This activity was very 
successful. After it became apparent that we 
couldn’t stay connected to Sacramento, the goal 
became to get the traffic as close to there as 
possible. We sent several CQ messages to San 
Francisco, which was outside of the simulated 
affected area, and attracted the attention of a 
ham with file store capabilities. We transferred 
two hours of accumulated traffic in short order to 
San Francisco, through four digipeater hops. The 
San Francisco station then transferred the traffic 
to the Sacramento station though two hops, again 
with little diff iculty, Later in the afternoon as 
the paths improved, we were able to transfer 
traffic directly to Sacramento. 


We learned these lessons during the test: First, 
two teams are needed at the packet position in the 
communications trailer. One team establishes and 
maintains the link, the other enters the traffic 
on a separate computer system. When a link is 
available, the data can be moved quickly by moving 
a disk from the data-entry computer to the 
computer with the TNC attached. During the 
“quake ," even though two computers were available, 
message traffic piled up in the “IN” basket while 
we were trying to establish a path. Once contact 
was made with the San Francisco station, it took 
half an hour to clear the backlog. It would have 
taken less than five minutes had the data already 
been entered on disk. 


We also learned that it would have been better if 
we had planned on an intermediate file relay 
station part way up the link in the first place. 
The cumulative effects of dropped packets 
increases with number of digipeaters until the 
probability of a packet making it all the way to 
the end and the ACK getting all the way back 
becomes small. In our case, four hops was 90% 
reliable (one packet not ACKed in 10), but seven 
hops was less that 10% reliable. Had we sent all 
traffic with to the intermediate station in San 
Francisco, we could have passed the traffic as it 
came in, instead of building up a large backlog. 


Finally, we learned that it was possible to pass 
traffic a long distance through a large number of 
digipeaters, provided that we did it the right 
way. It was possible to maintain a clear channel; 
people with non-simulated-emergency traffic stood 
by or went elsewhere. We also learned that as 
with other types of emergency exercise, success 
depends on planning and on the hard work of many 
amateurs. 


At the risk of leaving someone out, here is a list 
of the packet participants in “Quake 85" -- 
keyboarders, mountain-toppers, HQ and other off ice 


DC SUPPLY FOR TAPR TNC 

Gary Field, WAIGRC, is selling a converter that 
powers the TAPR TNC 1 from an unregulated source 
of 12 to 14 volts dc. The 3-inch by 4.5-inch 
converter board requires no modif icat ions to the 
TNC. Gary’s product announcement states that "a 
typical TAPR TNC draws approximately 0.75 amps 
when connected to 13.6-V dc.” Gary is selling 
complete kits for $20. 


If you are interested in a de supply for your 
portable or emergency packet station or for your 
digipeater, write: 


Gary Field, WAIGRC 
5 Pluff Ave. 
N. Reading, MA. 01864. 


Packet Radio Association has a 
that for the TAPR 
TNC. Their correct address is in Gateway Issue 


From WAlGRC. 
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XEROX 820 ROUNDUP 


The Xerox 820 is a single-board Z80-based 
microcomputer with 64 kbytes of RAM, two serial 
I/O ports, a parallel I/O port and a disk 
controller. In 1984, Xerox made these computers 
available at surplus prices, and packet-radio 
experimenters throughout the U.S. bought them. 
With hundreds of Xerox 820s in the hands of 
packeteers, it was not long before packet-radio 
applications software was available. The 
following is a list Xerox 820 software and 
hardware produced “by and for packeteers.” 


The MailBox and Gateway programs written by Hank 
Oredson, W@RLI, work with a Xerox 820, 8-inch disk 
drive(s) and one or two TAPR TNCs. The MailBox is 
an excellent packet-radio bulletin-board system, 
with Hank’s message forwarding routines, file 
uploading and downloading and extensive user 
logging. The MailBox can be connected to two TNCs 
to provide a message-storage node for two 
networks. If you use 2 TNCs, the Gateway program 
allows a station connected to one of the TNCs to 
initiate connections using the other TNC. The 
Gateway is most often used to link VHF networks to 
HF stations but can also be used in areas where 
there is activity on two VHF frequencies. To 
receive the latest version of the MailBox and 
Gateway, send an 8=inch disk, a disk mailer and 
return postage to: 


Hank Oredson, W@RLI 
19 North Hill Road 
Westford, MA 01886. 


The ‘820 has enough parallel and serial I/O ports 
to be used as a TNC, if you have the necessary 
hardware and software. There are two hardware 
modifications used to make the Xerox handle the 
HDLC protocol that is the basis of AX.25. The 
“FAD board” is an HDLC board that replaces one of 
the parallel I/O chips on the Xerox with a 28530 
serial communications controller (SCC). This 
board, designed by Howard Goldstein, N2WX, was 
first described in the newsletter of the Florida 
Amateur Digital Communications Association 
(FADCA). Since then, the Tucson Amateur Packet 
Radio Corp. (TAPR) has made bare PC boards for the 
FAD board available. The original run of these 
boards has run out, but more should become 
available this summer. The Z8530 chip is 
available (in limited quantity) from FADCA: 


FADCA 
812 Childers Loop 
Brandon, FL 33511. 


The second approach to HDLC is to use a serial I/O 
(SIO) chip (already on the Xerox 820) and an 
external state machine. The state machine 
recovers clock information and converts data to 
and from the NRZI format used by AX.25. The 
state-machine schematic and listings of the state- 
machine PROM are available from Gateway for an 
S.a.S.e. 


When you have selected hardware for your Xerox 
820, there are several software choices. FADpad 
is a TNC program, written by N2WX, that supports a 
single AX.25 link at a sustained data rate up to 
9600 bit/s. The software is the same as that in 
the TAPR TNC 2, and the user interface is 
compatible with most TAPR commands and procedures. 
To use FADpad, you must have a FAD board. FADpad 


is available as a pair of customized 2764 EKPROMs 
from: 


Ted Huf, K4NT.A 
1829 NW Pinetree Way 
Stuart, FL 33494. 


A CP/M .COM file for FADpad is available if you 
send an 8-inch disk and sufficient return postage 
to: 


Howard Goldstein, N2WX 
POB 905 
Melbourne, FL 32901. 


Phil Karn, KA9Q, has written a C program that can 
support multiple simultaneous AX.25 connections on 
a single Xerox 820. This program runs on the 820 
under CP/M with either the FAD board or the SIO 
and state machine. Send an 8=-inch disk and return 
postage to: 


Phil Karn, KA9Q 
25B Hillcrest Rd. 
Warren, NJ 07060. 


The ‘820 can also be used -- without disk drives, 
monitor or keyboard -- as a digipeater. Jon 
Bloom, KE3Z, has developed multiport digipeater 
software for the Xerox. The software can be used 
to link networks different frequencies, or it can 
be used as a simple single-port digipeater. It 
uses the SIO and two state machines for HDLC 
output. To receive this software, send a disk to 


Gateway. 


Where do you get a Xerox 820 if you want one? 
Since the computers are no longer produced, 
supplies are erratic, but persistent calling to 
the Xerox outlet will usually turn some up. Their 
phone number is 214-960-3367. 


If you want more information about the Xerox 820, 
you may be interested in Micro.Cornucopia 
magazine. “Micro C" is dedicated to single-board 
computers and has a Xerox column. 


Micro. Cornucopia 
P.O. Box 223 


Bend, OR 97709 


Remember, the ARRL and_Gateway in no way endorse 
the above products. The people making this 
software and hardware available are amateurs, not 
commercial vendors; send a disk if you want one in 
return; include sufficient postage; be patient. 


Kd. 


APPLE PBBS NOT AVAILABLE 


Lynn Taylor, WB6UUT, may not be able to accept any 
more requests for the packet bulletin-board 
software discussed in Gateway Issue 6 and 
elsewhere. If you want a copy of the software, 
please contact Lynn before you send any disks. If 


. you are already waiting for return disks, they 


will be sent soon. 


From WB6UUT. 


HAL OFFERS TNC 


HAL Communications Corp., a mainstay of amateur 
and commercial RTTY and AMTOR, has announced that 
it will be marketing a packet-radio controller, 
the RPC-1000. The gentleman at the HAL booth told 
me that the RPC-1000 was “essentially a TAPR TNC.” 
The RPC-1000 is targeted primarily at nonamateur 
users and will sell for $995. 


Another interesting item that HAL had on display 
was the WX-1000 “Weather Box.” This device gets 
input from a National Weather Service Wire Hookup, 
and provides the following outputs: local console, 
printer, phone-line modem, radio modem and alarm 
Sw itches. The WX-1000 might make an interesting 
addition to an amateur repeater or packet-radio 
network, since it provides up-to-the-minute 
weather reports and forecasts. 


Kd. 


TEXAS EMERGENCY EXERCISE 


On April 19, eight members of the Texas Packet 
Radio Society participated in the Civilian 
Military Contingency Hospital System exercise. 
This exercise involved flying simulated casult ies 
into three area airports, and transporting 
patients by ground ambulance, bus, or helicopter 
to one of seven hospitals in Tarrent county and 
eleven in Dallas county. 


Six amateur packet-radio stations and several 
voice-only amateur stations participated. Five of 
the packet-radio stations were at sites that had 
never used packet radio before. All three 
airports, two hospitals and the city of Dallas 
emergency operations center (EOC) were equipped 
for packet radio. Each location had file storage, 
off-line editing and a printer. The plan was to 
compose a standardized message off line and send 
it via packet to the Dallas EOC. The EOC station 
would then merge the lists received from the field 
stations and create a sorted, master list. This 
list would be sent, in connected mode, to the five 
field stat ions. 


The operation, while not flawless, went very well. 
The Parkland Hospital (Dallas County Hospital) 
received 24 kbytes of text in nine files. Each of 
these was printed and given to the hospital 
administration. The Garland Memorial Hospital and 
Carswell AFB locations also gave printouts to the 
officials present. 


David Cheek, WA5MWD reports: “We learned several 
lessons. First, text entry can be painfully slow. 
Special attention needs to be paid to this. item. 
Second, different message formats can destroy any 
merging and sorting efforts; all stations must use 
the same format. Third, bring back up copies of 
essential software, and check computer to TNC 
handshaking before it is needed. Fourth, a 
reliable formofadcast must be developed to 
distribute information that is essential to all 
participating stat ions. Even with these problems, 
however) use of packet radio shifted emphasis from 
getting the messages across the radio links to 
getting them correctly into the links. The speed 
of packet radio allowed us to concentrate on tasks 
that we may not have had time for before.” 


Via WA5SMWD. 


NEW PBBS IN ALASKA 


During a recent trip to Alaska, Tom Clark, W3IWI 
helped install “the farthest-north packet-radio 
bulletin-board system” -- KL7GNG in Cleary Summit, 
Alaska. The PBBS, using a Xerox 820 and the W@RLI 
MailBox software, serves Fairbanks on 145.01 MHz. 
There are now only 3 users, but within a month or 
two there will be several more. Demonstrating the 
emergency and public service uses of packet radio 
and the PBBS to the Fairbanks ARC generated 
considerable interest, perhaps because of the high 
number of computers per capita in Fairbanks (they 
have to have something to do on those long, cold 
winter nights!). Tom Walyer, KL7GNG, indicates 
that he has plans to try to establish packet links 
between Fairbanks and Anchorage in the near 
future. 


Via W3IWI. 


HID-ATLANTIC PACKET RADIO COUNCIL 


The Mid-Atlantic Packet Radio Council (MAPRC) is a 
confederation of packeteers from southern New 
Jersey, eastern Pennsylvania, Delaware, Maryland 
and northern Virginia that is the network 
coordinating agent (NCA) for an area roughly 100 
miles in radius around Elkton, Maryland. The group 
meets every month or so at a mutually inconvenient 
rest stop on I-95. MAPRC coordinates 5 major 
packet-radio bulletin-board systems (PBBSs) and 
gateway stations (W3IWI, WB2MNF, AK3P, KS3Q and 
WB4APR-5) and the major digipeaters in its area 
(WB4JFI-5, W3VD-5, WB4APR-5, WB4APR-6, K3DSM-5, 
WA3KXG). MAPRC plans to expand the mid-Atlantic 
portion of EASTNET with high-speed VHF and UHF 
links in the near future. 


To reach MAPRC, write: 


Tom Clark, W3IWI 
6388 Guilford Rd. 
Clarksville, MD 21029 


Prom W3IWI. 


UNIX GATEWAY ON EKASTNET 


Jim Kutsch, KY2D, in Little Silver, New Jersey, is 
now operating a gateway between the EASTNET 
amateur packet-radio network and "Usenet-netnews." 
Usenet is a worldwide collection of computers 
sharing news articles. These articles are called 
the “netnews.” There are over 12,000 sites on 
Usenet, in the U.S., Hawaii, Korea, Japan and 
Europe. 


The KY2D-2 gateway, a 68000-based computer running 
UNIX, operates on the EASTNET network frequency, 
145.01 MHz, It allows EASTNET stations to read 
netnews articles in the "net.ham-radio" newsgroup, 
and provides a local newsgroup for messages of 
interest only to users of the KY2D system. 


To use the gateway, connect to KY2D-2 and wait for 
the "login:" prompt, then type “guest”. After you 
log in, you will receive some _ preliminary 
instructions. For more information on Usenet, see 
"Usenet: A Bulletin Board for UNIX Users,” by 
Sandra L. Emerson, Byte, October, 1983. 


Via DR NET. 
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DAYTON 


If last year’s Dayton Hamvention was where packet 
radio “came out of the basement,” at this year’s 
Hamvention packet “came into the store.” 
Commercial vendors Heath, Kantronics, GLB, HAL, 
AEA and Richcraft were all displaying TNCs. 
Kantronics, Heath and TAPR each had prominent 
packet-radio advertisements in the Hamvent ion 
program. Heath’s supply of TNCs lasted only until 
Saturday morning , and dealers reported good sales 
of the other TNCs. Friday’s packet forum was well 
attended, with between 100 and 200 people 
listening to three hours of presentations. A 
later forum on digital RF techniques was also 
popular. If the level of interest shown by 
amateurs at Dayton was a valid predictor, there 
will be a lot of new packeteers this summer. 


Ed. 


TAPR TNC 2, TIRY THC 


After months of secret planning, designing and 
testing, Tucson Amateur Packet Radio Corp. (TAPR) 
has unveiled a new TNC, the TNC 2. TAPR, a 
nonprofit research and deve lopment organ izat ion’ 
designed the TNC 2 to “prove new concepts and to 
raise money to fund other development projects.” 


The TNC 2, dubbed “tiny TiNC," measures about 6 
inches by 9 inches and is housed in a low-profile 
cabinet. A CMOS Z80 CPU and other CMOS ICs keep 
power consumption below 260 mA at 12-V dc. The 
TNC 2, unlike TNC 1, does not use ac power; it 
requires a dc supply between 10 and 15 V. Packet 
(HDLC) I/O and clock recovery are performed by a 
Z80 SIO chip and a state machine. This hardware 
permits full-duplex packet operation. Like the 
modem in the TNC 1, TNC 2 modem uses the EXAR chip 
set with a switched-capacitor input filter. There 
is a modem-disconnect header for connecting 
external modems. The TNC 2 comes with 16 kbytes 
of EPROM and 8 kbytes of RAM and can be expanded 
to 56 kbytes total memory. In place of the 
nonvolatile RAM found on TNC 1, the TNC 2 uses a 
lithium-battery backed-up RAM for storage of user- 
setable parameters. 


The software for TNC 2 was written in Z80 assembly 
language. It provides the same user commands as 
are found on TNC 1, with a few additions and 
deletions. The support of VADCG protocols is 
gone, and in its place comes the ability to select 
either AX.25 Version 1 or Version 2. The software 
also keeps a list of stations heard, will send a 
message to connecting stations and can display the 
digipeater paths for monitored frames, to describe 
only a few of the enhancements. 
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The best feature of TNC 2 may be its price -- less 
than $200. 


So that TAPR isn’t deluged by phone calls, a few 
of the questions most frequently asked by those 
who saw the TNC 2 at Dayton will be answered here: 


What about TNC 1? The TNC 1 is no longer produced 
by or available from TAPR, but TAPR software 
support will continue. Heath, AEA, HAL and 
Kantronics are selling TNCs based on the TNC 1, so 
the TNC 1 is not “outmoded.” 


What is on TNC 1 that is not on TNC 2? The TNC 2 
has only one set of stored operating parameters, 
it has no ac power supply, and it has no parallel 
status port. (To replace the parallel port, TNC 2 
has connect-status and buffer-status LEDs.) 


When can I order a TNC 22 TAPR is not sure 
exactly when the TNC 2 will be available. There 
are now some units being tested, but it will 
probably be late summer before the first few kits 
are sold. Even after this, supply will probably 
be lower than demand. 


Can I get on a waiting list? No. Wait for an 
announcement, or buy one of the commercial TNCs. 


Congratulations to those responsible for both the 
TNC 1 and the TNC 2. While it is impossible to 
name all of the people involved in the TNC 2 
project, it is important to note that the "TAPR" 
team includes members of several organizations, 
including FADCA, SLAPR, RMPRA and CAPRA. TAPR’s 
efforts have been responsible for a lot of growth 
in packet radio, and the TNC 2 indicates that TAPR 
will be advancing packet radio whenever it can. 


Ed. 


HEATH TNC ADD-ONS 


Attached to the several Heath HD-4040 TNCs on 
display at Heath’s booth at Dayton were small 
cases with LEDs monitoring TNC status. These 
status indicators decode the signals available at 
the HD-4040 parallel output, and display buffer 
status, connect status and other TNC vital signs. 
The status indicator should be available by this 
fall and will make a nice addition to any TNC that 
uses TAPR hardware. Another TNC add-on that may 
become available from Heath is a tuning indicator 
for HF and OSCAR operation. This interest in 
packet peripherals displays Heath’s hopes that 
packet will draw some of its computer customers 
toward amateur radio. 


Ed. 


1985, and will be considered for publication in 


the premiere edition of The AMSAT Technical 


Journal, to be published in December of 1985. 


Via Amateur Satellite Report. 


BOOK REVIEW 


“Computer Networks” by Andrew S. Tanenbaum, ISBN 
O-13-165183-8. This is a very complete but 
readable reference on the entire subject, ranging 
from data transmission at Layer 1; through channel 
access techniques for satellite and packet radio 
broadcast channels; up through link, network and 
transport protocols (with a balanced and 
insightful coverage of the virtual-circuit and 
datagram protocols). Later chapters deal with 
presentat ion and application layers, with 
encryption and authentication given fairly good 
treatment. Tanenbaum is a good writer, able to 
explain things well and with a relaxed, often 
humorous style. 


From KA9Q. 
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amateur packet radio, with workshops covering 
topics as basic as how to hook up a packet-radio 
station and as advanced as Level-3 protocols. 
Other clinics planned include Packet Operating 
Procedures, New Equipment Demonstrations, Xerox- 
820 Operat ion and Modif icat ion, Commodore Computer 
Interfacing and TNC Theory and Interfacing. 


For further information on the SOQUTHNET Packet 
Conference, contact: 


FADCA 
812 Chliders Loop 
Brandon, FL 33511 


or 


GARC 

c/o Joe DiPietro, WA4NWO 
5010-135 N. Waldo Road 
Gainesville, FL 32601. 


From WIBEL, WA4NWO. 


OHIO GATEWAY. 


Steve Peterfreund, KAlPN, is running a W@RLI HF 
Gateway in Hudson, Ohio. Local users can connect 
on 145.01 MHz, and HF packet operators should look 
for KAlPNon 40, 30 or20 meters. 


via KAIPN. 


PACKET IN.NEBRASKA 


Mike Nickolaus, NF@N, reports that there will be a 
packet-radio seminar at the Nebraska Mini- 
Convention, on May 4th. Mike also sends the 
following report on packet radio in Nebraska: 


“Most of the packet activity in Nebraska is in the 
eastern half of the state. However, digipeaters 
are being placed in several new locations in the 
western part of the state, and a link from the 
eastern border to the western border is near 
completion. All Nebraska digipeaters are 
operating on 145.01 MHz. The Tekamah digipeater 
is the link that ties Nebraska to Iowa, and the 
KCGOJ MailBox, in Battle Creek, Iowa, has inputs 
on both 145.01 MHz and 147.555 MHz (the frequency 
used by most Iowa stations).” 


From NF@N. 


HIGH-SPEED LINKS 


There will soon be a test link between downtown 
Chicago, Illinois and La Port, Indiana using the 
9600-bit/s, 220-MHz modems designed by Steve 
Goode, K9NG. The link will initially use a Xerox 
820 board with multiport digipeater software. 
This is also what the WESTNET and EASTNET 
experimenters intend to do to enhance their 
current 2-meter digipeater paths. Groups in 
Florida and Iowa are also going to be using the 
9600-bit/s radios with their own Xerox 820 
software. Each group experimenting with the 9600- 
bit/s links should keep the other groups informed. 


From K9NG. 


RETWORK-LEVEL PROJECTS 


The third meeting of the CAPRA layer-3 networking 
committee was held on April 18th. Discussion 
centered on methods of implementing the datagram 
protocols TCP and IP over the CAPRA test link 
between Indiana and Chicago. Installation of the 
220-Mhz radios and antennas for the link is 
proceeding on schedule, and should be complete 
sometime within the next two months. Source code 
(in the C Language) for TCP and IP will be 
acquired within the next two weeks, and the 
committee will examine this code to see what 
changes have to be made to make it fit for amatuer 
radio use. The committee is also examining the 
68000 microprocessor as a network-control 
processor (as are a number of other groups). 


From K9NG. 


FAD BOARD PARTS. 


The Florida Amateur Digital Communications 
Association (FADCA) has made a_ purchase of Z8530A 
SCC chips for use with the FAD board on the Xerox 
820. These ICs are available for $20 postpaid; 
this is a remarkably good price on a hard-to-find 
part. If you need an Z8530A, write: 


FADCA 
812 Childers Loop 
Brandon, FL 33511. 


The FAD board replaces the parallel I/O chip on a 
Xerox 820 and is capable of handling 2 synchronous 
packet channels. Software for the 28530 is being 
developed by several groups, including FADCA and 
AMRAD. 


via WIBEL. 


PROJECTS UNDER WAY 


Several people have commented to me that they do 
not know what technical projects are going on and 
who is working on them. This lack of 
communication has not yet caused any large 
duplication of effort or “reinvention of the 
whee 1,” but it is surely slowing down certain 
projects. Although Gateway is not a technical 
newsletter, I will try to provide more news of 
technical interest. Please contact Gateway if you 
are working on a project that might be interesting 
to others. Don’t wait until you are finished to 
tell the world what you are doing; saying that you 
are investigating a problem is not _a commitment to 
come through with a completed product. 


Ed. 


AMSAT CALL FOR. PAPERS. 


AMSAT, The Radio Amateur Satellite Corp., Inc. has 
issued a call for professional papers reporting 
original work and/or signif icant findings in the 
field of low-cost satellite engineering, space 
communications, space sciences and related soc ial 
value issues. Suggested topics that are of 
interest to packet-radio experimenters include 
digital voice-encoding techniques, packet-radio 
techniques with emphasis on higher-level networks 
and teleports. Papers are due before August 1, 


traffic and general damage estimates were 
handled on the Z-meter ARES voice nets. 
Experiments were conducted using packet radio to 
replace all outgoing police calls (all outgoing 
phone lines’ from the police station were jammed) 
and to use packet radio for health and welfare 
traffic between an emergency relocation center 
and the police station. Attempting to replace 
voice communications (the downed’ phone lines) 
with packet did not prove successful. Packet 
proved to be usable for the health and welfare 
traffic between the relocation center and _ the 
police stat ion. All in all I think the test went 
very well, especially considering that the 
packet stations were assembled the _ night 
before the drill. Two portable packet stations 
were provided for the links at the relocation 
center and the police station. A mobile 
digipeater was also provided. I think the main 
points brought out by the drill are that a 
standard for TNC connectors would be helpful for 
throwing together emergency packet stations and 
that a standard packet health-and-welfare 
form should be agreed upon. Also, software to 
allow easy entry of messages in this form would be 
useful. Such software could be used to link 
emergency relocation centers, the morgue and a 
computer center. Lists of people at each center 
and the morgue could’ be kept at the central 
computer. Anyone looking for relatives would then 
ask the local relocation center to check the data 
base and see if they are at another center. I 
realize none of these observations are new but 
I would like to give encouragement anyone 
thinking of writing this kind of software.” 


[In the March issue of the Packet Status. Register, 
(newsletter of the Tucson Amateur Packet Radio 
Corp.) Jay Nugent, WB8TKL, sets forth a proposal 
for a standard “PACGram" -- a NTS radiogram sent 
via packet. Jay has written some software that 
facilitates entering and printing PACgrams. ~- Ed.] 


From K9NG. 


TRENTON PACKET FORUM 


The day-long packet-radio form at the Trenton 
Computerfest (April 20th) was attended by packet- 
radio enthusiasts from the length of EASTNET. 
Encouraging reports were heard from all parts of 
the network. 


Interest in 220-MHz linking was high, and some 
preliminary agreements were made, In general, 
those interested in high-speed linking agreed to 
use the K9NG FSK modems and the KE3Z multiport 
digipeater software. Ed Picchetti, K3RLI, is 
already running a 1200-bit/s, 220-MHz link between 
Wilkes-Barre, Pennsylvania and KB3ZW, in 
Honesda le, PA. Packets to be transmitted between 
these two stations are automatically switched from 
2 meters to 220 MHz, without user intervention. 
The KE3Z multiport digipeater software does much 
the same thing, with more versatile routing. 
Further discussions of EASTNET high-speed linking 
will take place on the informal EASTNET discussion 
net, Sundays at 8 P.M. on 3.855 MHz. 


The same network crowding that is making the 220- 


MHz projects important made _operating courtesy a 
hot discussion topic. The availability of several 


commercial TNCs will certainly result in an 
increase in the number of novice packet-radio 


operators on the air. With increasing network 
population, it is important that we all follow a 
few simple operating rules: 


1) Send CQ packets only when you are actively 
seeking to contact someone, not whenever your 
station is on the air. 


2) Send QST packets only if you have information 
of immediate interest to everyone on the 
network. 


3) If you must send QST or CQ packets, send them 
only through one digipeater and send them 
infrequently. 


4) Send packets of reasonable length. Packets of 
40 or 80 characters are much less likely to be 
in collisions than longer packets. 


5) Monitor the network before you connect to a 
bulletin-board system. Remember that a PBBS 
sending a long newsletter or message may 
monopolize a frequency; perhaps you can wait 
and connect to the PBBS when other stations are 
not using the network. 


6) Always move off of the main network frequency 
(145.01 MHz for EASTNET) if you are in a direct 
(no repeater) connection, 


Those at the Trenton forum, and experienced packet 
operators everywhere, encourage everyone to follow 
these rules and to remember that every packet that 
sent affects every station on the network. 


Thanks to Jon Pearce, WB2MNF, and Harold Winard, 
KB2M, for organizing the events at the Trenton 
Computerfest. 


Ed. 


TEXAS PACKET CLUB 


The Texas Packet Radio Society (TPRS) is taking 
shape in the Dallas-Ft. Worth area. TPRS has 
voice net Wednesday nights at 8 P.M. on the 
146.01/.61 MHz repeater. David Cheek, WA5MWD, is 
running a WORLI MailBox on 145.01 MHz, and is 
looking for other MailBox operators in Texas, 
Arkansas or Oklahoma that are interested in 
message forwarding. Traffic handlers in the area 
are looking for a way to use the MailBox for 
message handling. TPRS expects to have a wide- 
coverage digipeater operation on 145.01 MHz by the 
end of April, and they want to hear from anyone 
interested in constructing regional network. For 
further information, contact: 


Texas Packet Radio Society 
P.O. Box 835873 
Richardson, TX 75083 


Via WASMWD. 


SOUTHNET PACKETCONFERENCE 


The SOUTHNET packet Conference, cosponsored by The 
Florida Amateur Digital Communications Association 
(FADCA) and the Gator Amateur Radio Club (GARC), 
will be held at the University of Florida, in 
Gainesville, Florida on June 15 and 16, 1985. The 
conference will address a wide range of topics in 
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AUTOMATIC CONTROL OF DIGITAL COMMUNICATIONS 


The FCC has responded to the ARRL petition for 
rule making that proposed allowing automatic 
control of digital communications on frequencies 
above 50 MHz. The response is PR Docket No. 85- 
105, Notice of Proposed Rule Making 4879, Parts 
of the NPRM are reproduced below. 


“The Commission has received a petition from the 
ARRL, seeking to amend the Amateur Radio Service 
Rules to permit automatic control of digital 
communications on all amateur frequencies above 30 
MHz. The ARRL notes that Part 97 currently 
contains provisions for automatic control of 
stations in repeater, auxiliary and beacon 
operation but makes no provision for automatic 
control of routine digital communications. In 
support of its petition, the ARRL states that a 
variety of digital [modes] such as 
radioteleprinter, trans fer of computer programs, 
direct computer-to-computer communications and 
packet switching’ systems lend themselves to a 
mode of amateur-radio transmission where a control 
operator need not be present. According to the 
ARRL, present microprocessor and computer 
technology now routinely present at amateur 
stations can automatically transmit and receive 
digital communications, verify receipt of messages 
and respond to inquiries. ‘The ARRL notes that the 
use of Computer Based Message Systems (CBMS) are 
something new in amateur communications and should 
be encouraged by more experimentat ion, including 
automatic control which is both feasible and 
necessary to facilitate further development in the 
art of amateur radio. Two timely comments were 
filed. Both supported the petition for rule 
making. 


“Automatic control in the Amateur Radio Service 
has previously been approved for repeater, 
auxiliary links and beacon operations. With an 
ever-growing list of amateur operations where 
automatic control is permitted, we believe that 
now may be the appropriate time to expand 
automatic control to all amateur operations, 
prohibiting its use only in those situations where 
there is a justifiable reason why automatic 
control should not be allowed. Therefore, we 
invite amateur radio operators in general, and 
amateurs experienced in automatic control in 
particular, to submit comments calling to our 
attention any problems that may arise by expanding 
automatic control to encompass all amateur radio 
operations. Our goal is to keep the amateur 
service abreast of technological developments and 
to utilize new technology, such as CBMS, where 
appropriate. On the other hand, we do not want to 
introduce any innovations into the service which 
would be disruptive of amateur communications or 
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which would essentially change the character of 
the serv ice. 


“We propose that any amateur radio station may be 
under automatic control, except when transmitting 
on frequencies below 29.5 MHz. As noted earlier, 
the petitioner did not request automatic control 
below 30 MHz. However, since automatic control is 
already permitted for repeater operation between 
29.5 and 29.7 MHz, it is reasonable to make the 
lower limit for automatic control 29.5 MHz, rather 
than 30 MHz. 


“These proposed rule amendments would still 
prohibit automatic control operation in any 
instance where the station is transmitting third- 
party traffic. This in in accord with Section 
97.79 (d) of the amateur rules which specifies 
that a control operator must always be present 
when a third party is participating in amateur 
radio communications.” 


The complete text of the NPRM is available from 
the ARRL Information Services Department. Send an 
8.a.8.e. with 39 cents postage, and ask for RM- 
4879. 


It is important that interested packet-radio 
operators, especially the operators of bulletin 
boards, file comments on both the intent and the 
implementation of this NPRM. The deadline for 
comments is June 25. A formal filing requires that 
you file an original and five copies of your 
comments and other materials. If you want each 
Commissioner to have a personal copy of your 
comments, send 11 copies. Please also send any 
formal or informal comments on the NPRM to the 


ARRL,. 
Ed. 


SIMULATED EMERGENCY TEST 
Steve Goode, K9NG, files the following report: 


“On April 20 the Chicago Area Packet Radio 
Association (CAPRA) participated in a simulated 
emergency test (SET) in conjunction with the 
National Weather Service, the Northwest Illinois 
ARES and the Village of Hanover Park, Ill. The 
simulation stated that at 9:35 A.M. a tornado 
touched down in Hanover Park creating a 100- 
yard path of destruction running d iagona 1 ly 
through the village. An Emergency Command 
center was set up at the Hanover Park po 1 ice 
station under the command of the Village Chief of 
Police. Liaison officers ‘to the police and fire 
departments and to the amateur radio net were 
under the chief’s command. Initial weather 


messages from one network to another, because 
there is no standard format for presenting 
subject, destination, source and distribution 
information in a message header. The committee 
agreed to study the X.400 series of message 
protocols and attempt to develop a subset of these 
standards that would meet the needs of amateur 
packet red io. 


Prom W4RI,. 


PACKETF REQUENCIES 


The CVRA-Southeastern Repeater Association, Inc. 
coordinates repeaters in North Carolina, South 
Carolina, Tenessee, Virginia and West Virginia. 
CVRA has established 145.01, 145.03, 145.05, 
145.07 and 145.09 as packet-radio frequencies. 


From K4AR0. 
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“Phase I of WESTNET’s 1985 plans is to install 
145.01 MHz repeaters in southern California, This 
will remove the need for frequency translation, 
reducing the maximum number of digipeater hops to 
five, with only three hops between L.A. and San 
Francisco. This will result in an immediate 
improvement in network service. 


“Phase If is to install multi-port digipeaters, 
220-MHz radios and 9600-bit/s modems at each of 
the digipeater sites. Each digipeater will be 
linked to its neighbors at the higher speed and 
frequency, providing user access to that link via 
145.01 MHz at 1200 bauds. This will avoid 
collisions between local traffic around each 
digipeater with traffic on its way to a more 
distant point. While not as good as a true 
network protocol, this will be much better than 
current, single-frequency linking. 


“Since the multi-port digipeater is implemented on 
surplus Xerox 820 boards, WESTNET can switch to a 
true layer-three network when one becomes 
available. The Xerox 820 was designated as the 
target hardware for the first prototype layer- 
three network software. 


“Once in place, WESTNET will allow a user to use 
the network as if it were a simple chain of 
digipeaters. The user will transmit and receive 
on 145.01 MHz. If he specifys more than one 
digipeater, his packet will be repeater between 
digipeaters at 9600 bauds on 220 MHz. The packet 
will be transmitted on 145.01 MHz by the last 
digipeater in the list, Standard digipeaters can 
be used on 145.01 MHz as far as necessary for a 
user to access a multiport digipeater site. 


“It is expected that by 1986 and certainly by 
1987, there will be a true network-layer protocol 
in place, and that the backbone network will move 
toward 1.2 GHz at 56 kbits/s. We also suspect 
that 145.01 network-access and digipeater 
capability will always be needed to handle entry- 
level users, as a redundant path for network 
resilience in case of emergency and to handle 
users in extreme outlying areas. 


“It was agreed that the 220-MHz link frequency is 
220.950 MHz. The modem standard is the K9NG 9600- 
bit/s modem. The controller is the Xerox 820 
running the KE3Z multiport digipeater software, 
WESTNET technical coordination will take place on 
the W6IXU mailbox.” 


If you are interested in schematics of the K9NG 
modems, they are published in the proceedings of 
the Fourth ARRL Computer Networking Conference, 
The mulitport digipeater software is available for 
an 8” disk to Gateway at the ARRL. I hope that 
Harold’s report provides some insight into how 
packet radio is changing in areas where the 
activity is overflowing a single 1200-bit/s 
channel. 


Via DR NET. 


EASTNET GROWING 


The addition of several new stations to EASTNET 
has connected the network from Ottowa, Canada, to 
Washington, D.C. The “missing link” in northern 
New Jersey has been filled by WA2SNA-2, installed 
by the Ramapo Mt. Amateur Radio Club. Now, mail 


can be forwarded from the W3IWI MailBox in 
Washington, through WB2MNF in southern New Jersey, 
and on up the network to WA2RKN in Hyde Park, NY, 
WIAW in Newington, CT, or any of the W@RLI 
MailBoxes in the Boston, MA area. Because of high 
local activity at many places in the network, 
real-time, long-distance connections often are 
impossible or slow. W@RLI-type store-and-forward 
messages traverse the network relatively well, 
though . 


The WORLI MailBox and Gateway software for the 
Xerox 820 has is providing much of EASTNET (and 
beyond) with packet-radio message service. All of 
the following stations are linked in this store- 
and-forward network: 

WORLI - Westford, MA 

KIBC = Lexington, MA 

KE1G-1 = Goffstown, NH 

NIDKF =~ Cranston, RI 

KAIT = Harvard, MA 

W1AW-4 = Newington, CT 

WBIDSW =~ Manchester NH 

WA2RKN-2 = Hyde Park, NY 

WB2MNF - Medford, NJ 

W3IWI = Clarksville, MD 

KS3Q - Baltimore, MD 

AK3P ~ Humme ls town, PA 

K7PYK = Scottsdale, AZ 

WA4SZK = Florence, SC 


A message placed on any of these PBBSs for a user 
of any of the others will eventually be forwarded 
from node to node to the proper MailBox. Routing 
tables are maintained (by hand) at each node. 


To the north, the the Plattsburgh Amateur Packet 
Radio Association, a division of the Champlain 
Valley Amateur Radio Club, has installed some 
stations that link the Mt. Ascutney, Vermont, 
digipeater to Ottowa, Ontario. This path allows 
EASTNET stations to access a BBS run by Wayne 
Bruce, VE3FXI. For those of you on EASTNET who 
want to try out the path to Ottowa, use WAITLN-1, 
KD2AJ, W2UXC-l and VE3PAK. All of these 
digipeaters are on 145.01 MHz. 


via WORLI, Bd. 


DIGITAL COMMITTEE MEETING 


The ARRL Ad Hoc Committee on Amateur Radio Digital 
Communication met at the Networking Conference in 
San Francisco, The most important issues 
discussed by the committee were protocol standards 
for TNC control possible standards for message 
format. 


Doug Lockhart, VE7APU, is investigating the use of 
CCITT X.3, X.28 and X.29 protocols in amateur 
TNCse Doug’s paper in the conference proceedings 
outlines the need for a standard set of commands 
and messages on amateur radio TNCse If TNC 
programmers used standard commands and messages, a 
single article could describe how to operate all 
amateur-radio TNCse If standards were adopted and 
adhered to, applications programs like the W@RLI 
MailBox would could use any TNC. The Committee 
expressed its appreciation for the research that 
Doug had done and requested that he deliver a 
draft of a proposed standard as soon as possible. 


Hank Magnuski, KA6M, and several other PBBS 
operators discussed how difficult it is to move 


We welcome the Packet Communicator to the growing 
list of commercially-available TNCs. The 
Kantronics packet-radio motto? “Packet Made 
Easy! " 


Via_Computers and Amateur Radio. 


SEAS A Ee | Ce 


Due to a letter to Gateway from Thomas Clements 
III, W1ICH, the ARRL Contest Advisory Committee 
(CAC) has approved a Fie 1d Day packet-radio bonus. 
Field Day rules will now read: “An additional 100 
points can be earned by completing at least one 
QSO on packet radio during the Field Day period. 
The repeater provision is waived for packet-radio 
QsOs. A packet station does not count as an 
addit ional transmitter. On the summary sheet, 
show packet radio as a separate “band.“ This new 
bonus is in effect this year, thanks to quick 
action by the CAC. 


Field Day, always a day of high visibility for 
Amateur Radio, is now a good time to show the 
public and the members of your Field-Day group the 
advantages of packet radio, Amateur Radio’s newest 
mode. Show them that packet radio is no longer an 
experimental mode, but a valuable emergency 
communications tool. This Field Day bonus might 
also encourage some investigation of low-power 
portable packet stations. TNC, two-meter rig and 
portable computer might all be run from solar, 
wind or human power. 


Mr. Clements suggests that “the annual Field Day 
message be sent to the section manager by packet 
radio if possible. Perhaps some traffic handling 
nets could arrange to pick up messages from 
packet-radio bulletin boards.” 


If you have any interesting ideas for using packet 
radio during Field Day, send them along to 
Gateway. Also, be sure to take some pictures of 
your portable packet station for the QST Field Dgy 
summary. 


Ed. 


TRANSCONTINENTAL PACKET 


At the meeting of the Board of Directors of the 
Pacific Packet Radio Society (PPRS) on March 2lst, 
1985, the following resolution was passed: 


Whereas the PPRS was one of the first societies 
formed specifically to encourage the growth of 
computer networking via radio using all digital 
concepts and techniques, and whereas the San 
Francisco area was the site of the nation’s first 
amateur digipeater, and whereas an even greater 
challenge faces the amateur radio community to 
establish a transcontinental link, the Pacific 
Packet Radio Society has decided to establish a 
unique award to encourage the completion of the 
first terrestrial transcontinental network link. 
This one-time award shall be known as the “Golden 
Packet” [Like the golden spike that completed the 
transcontinental railroad. = Ed.] and _ the 
regulations relating to it are listed below: 


1. A transcontinental link must be established, 
with each terminus located within 100 kilometers 
of either the Atlantic or Pacific Ocean. 


2. The system must consist of fixed terrestrial 
digital store-and-forward radio links using VHF 
(greater than 144.1 MHz), UHF or microwave 
frequencies. Use of HF, satellite, tropo, meteor- 
scatter or moonbounce channels is prohibited. 


3. A valid two-way transmission and acknowledgment 
of previously unknown information (256 characters 
or more> must occur in less than ten minutes. 


4. This competition is open to licensed North 
American amateurs, and no commercial links or 
services may be used in the path. Club stations 
are permit ted. 


5. Proof of the exchange must be submitted to the 
PPRS. Proof must include a list of the stations 
in the link, their locations, frequencies used and 
a copy of the text exchanged. 


6. The reward shall consist of a suitably engraved 
plaque with the names of all participating 
stations listed which shall be presented to the 
ARRL. Each participating station shall receive 
either a plaque or a certificate. 


7. Final decision on the award is subject to 
review and approval by the Board of Directors of 
the PPRS. 


From KA6M. 


WESTNET MEETING 


The second “official” meeting of WESTNET was held 
in conjunction with the Fourth ARRL Computer 
Networking Conference last week. The networking 
plans set forth at this meeting illustrate how 
most amateur packet-radio networks will advance. 
Several groups within EASTNET are making plans 
similar to the WESTNET plan. The following notes 
on WESTNET plans and the reasoning behind them 
come from Harold Price, NK6K. 


“The primary purpose of the first WESTNET meeting 
was to put in place the best network possible with 
the technology then available. It was hoped that 
linking San Diego through Los Angeles to San 
Francisco would help generate interest at the 
endpoints and in the less populous areas between, 
and that the increased number of users would 
supply the resources to build a more sophisticated 
network. We are now ready to proceed with the 
first in a series of improvements: a 9600-bit/s 
network backbone. 


"WESTNET decisions have been based on two 
concepts. First, use the best technology that is 
available, but don’t wait for the next innovation 
that is coming ‘real soon now.’ Second, don’t 
build anything that will make transfer to the next 
level of technology difficult. 


“What technology is there to use now? There is 
still no agreement on network-layer protocols. 
There aren’t even any working prototypes of 
network software. There is, however, a 9600-bit/s 
modem design, the ARRL lab’s multi-port digipeater 
software, hundreds of users running 1200 bauds on 
two meters and a chain of seven digipeaters 
between southern and northern California. 
Unfortunately, a frequency translation from 145.01 
MHz to 145.85 MHz is now necessary between north 
and south. 


Gateway 
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FOURTH ANNUAL NETWORKING CONFERENCE 


The Fourth ARRL Amateur Radio Computer Networking 
Conference, cosponsored by the ARRL and the 
Pacific Packet Radio Society (PPRS), was a 
complete success. More than half of the twenty 
four papers published in the proceedings were 
presented at the conference, with attendance 
around 100 throughout the six hour meeting. The 
PPRS/ARRL booth at the West Coast Computer Faire, 
inc lud ing on-the-a ir demons trat ions of packet 
radio at 1200 and 9600 bauds, generated a lot of 
interest. Several hundred handouts were given to 
interested Faire-goers, and a lot of radio 
amateurs who didn’t know about packet radio 
stopped by the booth to see the TNCs in action. 
Congratulations to Hank Magnuski, KA6M and the 
PPRS for coordinating a successful conference. 


The Proceedings of the Fourth ARRL Amateur Radio 
Computer Networking Conference are available from 
the ARRL for $10. See Gateway issues 14 and 15 
for abstracts of the papers of the papers is this 
109-page volume of proceedings. Proceedings for 
the first, second and third conferences are also 
available for $8, $9 and $10, respectively. These 
publications provide a valuable record of the 
history of packet radio, what packet-radio 
experimenters expect from the future and diverse 
points of view on many technical issues. 


TRENTONCOMPUTERFEST 


For those on the East Coast, there will be a large 
packet-radio meeting at the Trenton Computerfest, 
on April 20th. 


1000 Opening remarks ~ Harold Winard, KB2M. 

1010 ARRL remarks = Jeff Ward, K&8KA. 

1020 Introduction to packet = Jon Pearce, 
WB2MNF . 

1115 Regional summaries of packet activity. 

1245 Comparisons of packet-rad io TNCs. 

1345 Introduction to the W@RLI MailBox = Dick 
Kutz, KS3Q. 

1430 Packet-radio expert-panel discussion with 
Tom Clark, W3IWI, Phil Karn, KA9Q and Mike 
Bruski, AJ9X. 

1600 End of forum. 


The room-number for the forum is not available at 
this time; just ask at the Computerfest 
administration booth or look for posters. If you 
would like to make a presentation during the 
“regional summaries,” contact Jon Pearce, WB2MNF, 
at 609-953-1566, or Harold Winard, KB2M, at 201- 
361-6478. 


via WB2MNF. 
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DAYTON HAMVENTION 


Packet-radio will be well represented at the 
Dayton Hamvention, April 26, 27 and 28. The 
Dayton packet forum will be held on Friday, April 
26th from 2:30 P.M. until 5:30 P.M., in room 1. 
Six speakers will make presentations and answer 
questions from the audience. 


14380 Introduction to the packet forum = Bob Neben, 
K9BL 

1440 Telecommunications and the Amateur in the 
2lst Century - Rick Whiting, WOTN. 

1500 Packet Primer, 1985 = Pete Eaton, WB9OFLW. 

15380 Report on the ARRL and packet-radio 
technology = Jeff Ward, K8KA. 

1600 Update on TAPR = Lyle Jonhson, WA7GXD. 

1680 PACSAT update = Harold Price, NK6K. 

1700 Networking, bulletin-board systems, and the 
Xerox 820 computer = Terry Fox, WB4JFI. 


There will also be display booths for each of the 
major packet radio TNC manufacturers, including 
TAPR, GLB, Heathkit, AEA and Kantronics. 


Packeteers are encouraged to use 145.01 MHz 
(voice) as a coordination frequency. 


Via K9BL e 


KANTRONICS TNC 


Kantronics, makers of several RTTY and AMTOR 
software/hardware packages, have announced the 
availability of a TNC, the Kantronics Packet 
Communicator. An early production model of the 
Packet Communicator was displayed at the recent 
Computer Networking Conference in San Franc isco. 
The TNC is small, housed in a 2 X¥ 6 X 88-inch 
cabinet, much like the cabinet for the Kantronics 


UTU. 


Although Kantronics “took some cues from the TAPR 
TNC," the Packet Communicator is a new hardware 
design. The internal modem uses switched- 
capacitor filters and can be switched by software 
to provide either Bell 103 or 202 tones, with or 
without receiver equalization. Also, the Packet 
Communicator can be used as a Bell 202 modem, 
bypassing all packet-radio functions. The TNC can 
send and receive packets at 300, 400, 600 and 1200 
bit/s, half duplex. 


The Packet Communicator serial port can provide 
RS-232C or TTL signals, at 300, 1200 or 9600 
bauds. Special packet-radio terminal programs for 
many computers will be’ available soon from 
Kantronics. 


TRENTON COMPUTER FEST 


There will be a packet radio meeting at the 
Trenton (New Jersey) Computer Fest on Saturday, 
April 20 (note the change -- some of the earlier 
publicity had indicated Sunday). The Mid-Atlantic 
Packet Radio Council (MAPRC) is sponsoring the 
packet sessions and the organizers are Harold 
Winard, KB2M and Jon Pierce, WB2MNF. There will be 
a panel of experts to answer questions about 
packet radio and presentat ions by representatives 
of various EASTNET LANs. 


INTERNATIONAL PACKET ACTIVITY 


Although this report and list were biased toward 
U.S. packet activity, there is considerable 
activity in Canada and overseas. Japan, the U.K., 
New Zealand, Australia, Germany and Sweden all 
have packet radio activity. Canadian activity- 
centers include Hamilton, ON; Vancouver, BC; 
Toronto, ON; and Ottowa, ON. Back issues of 
Gateway provide more informat ion on international 
activity. 
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MASSACHUSETTS 


New England Packet Radio Assn. (NEPRA) 
P.O. Box 15 
Bedford, MA 01730 


MICHIGAN 


Eastern Packet Radio Of Michigan (EPROM) 
c/o J. Nugent, WB8TKL 

307 Ross Dr. 

Monroe, MI 48161 


MINNESOTA 


MAPR hosts a Tuesday-evening voice net on 
146.04/64 MHz at 7:45 PM. Packet operation is on 
145.010 MHz with additional channels on 145.3, 
145.5, 145.7, and 145.9 MHz. 


Minnesota Amateur Packet Radio (MAPR) 
C/O Pat Snyder, WAGTTW 

565 Redwood Lane 

New Brighton, MN 55112 


NEW HAMPSHIRE AND VERMONT 


Mt. Ascutney Amateur Packet Radio Association 
c/o Carl Breuning, N1CB 

54 Myrtle St. 

Newport, NH 03773 


NEW JERSEY 


0 The Radio Amateur Telecommunications Society 
provides support to amateurs engaging in packet 
activities. The group’s activities include a 
packet software library and development of a 
cross-state trunking system to be incorporated 
into EASTNET. A directory of active amateur 
packet stations and facilities has been compiled 
and is available. Standards documents are kept in 
club files and may be distributed upon request. 
RATS is developing an interface between the 
private teleconference DR NET and the EASTNET 
packet-radio network. This interface should be 
operat ing soon. 


In Northern New Jersey/New York City: 
The Radio Amateur Telecommunications Society 
(RATS -NORTH ) 


c/o J. Cordon Beattie, Jr. N2DSY 
206 North Vivyen St. 

Bergenf ie 1d, NJ 07621 

(201) 387-8896 


In South Jersey: 

The Radio Amateur Telecommunications Society 
(RATS-SOUTH) 

c/o Brian B. Riley, KA2BQE 

RD 2 Burnt House Rd. 

Indian Mills, NJ 08088 


RATS BBS Tel: 609-268-9597 (300 baud) 


0 The Cherryville Repeater Association is also 
active in packet radio in New Jersey. Their main 
concerns are public service and 220-MHz linking. 
They maintain a series of linked 220-MHz duplex 
repeaters that are used for voice and packet. 


Cherryville Repeater Association 
Box 308 
Quakertown, NJ 08868 


NEW YORK 


Rochester Packet Group 
c/o Fred Cupp, W2DUC 
27 Crescent Rd. 
Fairport, NY 14450 


0 New York City: 


Packet Of New York (PONY) 
c/o Bill Schimoler 

42-15 172 St 

Flushing, NY 11358 


0 Hudson Valley: 


The Mount Beacon Amateur Radio Club supports an 
active packet-radio group. They are now turning 
their attention and resources to 220-MHz network 
links. 


Mt. Beacon Amateur Radio Club 
P.O. Box 841 
Wappingers Falls, NY 12590 


OHIO 


Cincinatti Amateur Packet Radio Experimenters 
Society (CAPRES) 

c/o John Schroer-IV, KA8GRH 

984 Halesworth Dr. 

Forest Park, OH 45240 


Cleveland Area: 
Maynard Weston, W8MW 
4564 Park Edge Dr. 
Fairview Park, OH 44126 


TENNESEE 


Tennesee packet activity is centered in Memphis, 
on 145.01 MHz. Contact: 


John Burn ingham, WB8PUF 

Memphis State University 

Dept. of Engineering , Technology 
Memphis, TN 38152 


TEXAS 


Dave Cheek, WA5MWD 
1510 Treavis St. 
Garland, TX 75042 


UTAH 


UPRA has a voice net on Tuesday evenings, at 8:45 
PM, on 146,02/62 MHz. 


Utah Packet Radio Association (UPRA) 
4382 Cherry-view Drive 
West Valley City, Utah 84120 


WASHINGTON 


Northwest Amateur Packet Radio Association (NAPRA) 
c/o John Gates, N7BTI 

750 Northstream Ln. 

Edmonds, WA 98020 


While Sacramento packet stations are able to get 
into the San Francisco Bay Area with moderate 
success, plans are to install a high-level 
digipeater in the Sierra Nevada this year which 
will allow for more reliable links into the Bay 
area and down the Coast Range. Even better, the 
digipeater is planned to be a major node in the 
proposed Central Valley chain which will provide 
North-South path through the center of the state. 
SACPAC is also working on a WGRLI MailBox in 
Sacramento which should be functioning on 145.09 
MHz by early summer. SACPAC is coordinating with 
PPRS to ensure that operating parameters remain 
standardized not only between these groups, but 
also within the rapidly expanding group of 
newcomers to packet radio in this area. All local 
operations are on 145.01 and 145.03 MHz. 


The Sacramento County Office of Emergency 
Operations plans to have a TNC installed by the 
end of this summer and is coordinating with the 
State Office of Emergency Services to establish 
links and work out details for use of packet 
systems in emergency and disaster situations. The 
plan is to have packet “teams” within the 
County’s newly-revitalized RACES program and ARES. 
The teams would set up communications at 
appropriate sites during drills and actual 
emergenc ies. A good framework should be developed 
over the next year to accomodate the projected 
growth in this emergency network. 


0 LAPG is the local Los Angeles packet-radio 

club. LAPG 

8:00 PM local time on 145.36 MHz simplex. 
of every month 


Los Angeles Area Packet Group (LAPG) 
P.O. Box 6026 
Mission Hills, CA 91345 


0 The Southern California Digital Coordination 
Council (SCDCC) is an organization formed by the 
packet radio operators in Southern California to 
serve as a central point for communications 
between packet users and other amateur groups. It 
also serves as a clearing house for information on 
local packet activity. Membership is open to 
anyone; packet radio users are encouraged to join. 
SCDCC has a technical committee to help track and 
promote the rational growth of packet radio 
equipment, repeaters, gateways and protocols on 
frequencies assigned to packet radio. 


SCDCC serves all of Southern California and has 
members in San Diego, Los Angeles, Ventura, Santa 
Barbara, Lancaster, Lompoc, and other areas. 


SCDCC 
P.O. Box 6026 
Mission Hills, CA 91345 


0 The Pacific Packet Radio Society was one of 
the first North American packet-radio clubs. PPRS 
serves the San Francisco Bay area, and is the co- 
sponsor of the Fourth Amateur Radio Computer 
Networking Conference. 


Pacific Packet Radio Society 
P. 0. Box 51562 
Palo Alto, CA 94303 


0 There is also a packet-radio club in San 
Diego. 


San Diego Packet Group (SDPG) 
c/o Mike Brock, WB6HHV 

10230 Mayor Circle 

San Diego, CA 92126 


COLORADO 


Rocky Mountain Packet Radio Association 
% Andy Freeborn, NOCCZ, Secretary 

5222 Borrego Drive 

Colorado Springs, CO 

(303) 598-8373 


FLORIDA 


The Florida Amateur Digital Communications 
Association is an organization interested in 
digital communication techniques such as packet 
radio. Since its founding in 19838, FADCA has 
grown to be one of the major regional packet 
organizations in the nation. FADCA members are 
from Florida, Geo1gia, and many other states. 
FADCA provides a structure for planning orderly 
growth of packet networking, and has been 
designated as the agent of the Florida Repeater 
Council for administering packet frequencies and 
repeater sites. FADCA’s newsletter, the BEACON, 
provides technical information and operating news 
to over 250 persons each month. FADCA is the 
coordinator of the SOUTHNET packet network which 
is rapidly expanding from Florida through the 
entire Southeast. 


Florida Amateur Digital Communications 
Association (FADCA) 

812 Childers Loop, Brandon, FL 33511 

(813) 689-3355 


GEORGIA 


Georgia Radio Amateur Packet Enthusiast Society 
GRAPES 

P.O. Box 1354 

Conyers, GA 30207 


Southern Amateur Packet Society (SAPS) 
c/o Wayne Harrell, WD4LYV 

RT 1 Box 185 

Sycamore, GA 31790 


ILLINOIS 


Chicago Amateur Packet Radio Assn. (CAPRA) 
P.O. Box 8251 
Rolling Meadows, IL 60008 


St. Louis Area Packet Radio 
9926 Lewis & Clark 
St. Louis, MO 63136 


IOWA 


The Central Iowa Technical Society has helped 
build a widespread packet network throughout Iowa. 


Central Iowa Technical Society 
c/o Ralph Wallio, W@RPK 

RR 4 

Ind iano la, IA 50125 


KANSAS 


John Anderson III, WB¢SKL 
305 Brittany 
Olathe, KS 66061 
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SPECIAL ISSUE 


This issue of Gateway is tailored to provide 
information to those attending the West Coast 
Computer Faire and the Fourth Amateur Radio 
Computer Networking Conference. We have attempted 
to provide an overview of packet-radio activity in 
the United States and a fairly complete list of 
U.S. packet-radio clubs. 


PACKET RADIO_IN 1985 


The past year has seen packet radio grow from a 
few hundred isolated stations into a few dozen 
tentatively-connected local-area networks (LANs). 
There are now between 2,000 and 3,000 packet-radio 
terminal node controllers (TNCs) operating ‘on the 
amateur bands. The following list of clubs gives 
a fair idea of where the activity is concentrated: 
The San Francisco Bay area and the Los Angeles 
basin are the hotspots of “WESTNET” activity. 
These two centers are linked by a string of 
mountaintop repeaters. In the Northwest, there are 
organized groups pushing packet radio from 
Vancouver, BC toward Northern California. There 
are two paths taking shape from West to East: 
Arizona = New Mexico ~ Texas ~ Arkansas, and Utah 
- Colorado - Nebraska = Iowa = Illinois. The 
Chicago-area has recently produced a 9600-bit/s 
modem (designed by Steve Good, K9NG) and promises 
to be a center of network development. The east 
coast from Washington, D.C. to Boston is tenouosly 
linked, and there are many areas of high activity 
along this “EASTNET.” In the south, Florida has 
the largest packet-radio population, and Alabama 
and Georgia are beginning to come on-the-air. 
Terminal node controllers have been sold in every 
state in the U.S. and in several overseas 
countries . 


The U.S. is being covered by LANs, and the next 
leap for amateur packet radio will be to link 
these LANs using a “network-layer protocol.” Many 
LANs are already linked in a store-and-forward 
mail network designed by Hank Oredson, W@RLI. 
Hank’s MailBox software, running at dozens of 
sites throughout the world, forwards a message 
from one node to another, until the message 
reaches its destination. This taste of networking 
is driving several software and hardware teams in 
the development of real-time networking equipment. 


If you are excited by the idea of an amateur data 
network, or if you have some use for such a 
network (emergency traffic, weather networking, 
message handling, etc.) contact a packet-radio 
group and join the fun. 


Jeff Ward, K8KA, Editor. 
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NATIONAL ORGANIZATIONS 


o The Amateur Radio Research and Development 
Corp. is a group interested in advanced amateur- 
radio techniques. Members of AMRAD have been 
responsible for many advances in packet radio. 


AMRAD 
P.O. Drawer 6148 
McLean, VA 22106-6148 


o The Amateur Radio Satellite Corp. has ongoing 
interest in the development of amateur packet- 
radio standards, and they are currently involved 
in the construction of PACSAT, a packet-radio 
satellite. 


AMSAT 

850 Sligo #601 

Silver Spring MD 20910 
301-589-6062 


0 The Tucson Amateur Packet Radio Corp. (TAPR) 
is best known for the TNC kit that it designed, 
tested and markets. With the TNC now being 
produced by two commercial companies, TAPR 
continues to be instrumental in packet-radio 
development . 


Tucson Amateur Packet Radio (TAPR) 
P.O. Box 22888 
Tucson, AZ 8573402888 


ALABAMA 
In the Huntsville area, contact: 


Frank Emen s , W4HFU 
3714 Lakewood Circle 
Huntsville, AL 35811. 


Near Birmingham: 


Henry Wingate, K4HAL 
104 Von Dale Drive 
Birmingham, AL 35215 


ARKANSAS 


Elmer Wingf ie 1d , W5FD 
26 Belmont Drive 
Little Rock, AR 72204 


CALIFORNIA 


0 Recently, the Sacramento Packet Group 
(SACPAC) became a special interest group under the 
Sacramento Amateur Radio Club, Incorporated. This 
club, W6AK, is the area’s oldest ham club. 


If you live in the west, consider attending the 
Rocky Mountain Division Convention in Jackson 
Hole, Wyoming, August 2 through 4, There is a lot 
of packet activity planned for the Convention, 
including a presentation by Pete Eaton, WB9FLW. 


Prom N/7BHC, 


MORE READING 


“Designing and Implementing Local Area Networks,” 
by Dimitris N. Chorafas, McGraw Hill, 1984. This 
book provides a good overview of LANs. Not all of 
the discussion involves packet radio, but many 
interesting topics are addressed. 


FROM K1HOP. 
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“Another Application Note Describing a Low-Power 
RS232-Like Interface,” by Paul Newland, AD71 -- A 
new and improved low power RS$232-like interface is 
discussed. It features half the power consumption 
of the interface presented in a previous paper, 
and it uses fewer parts. 


“A Few Thoughts cn User Verification Within a 
Party-Line Network,” by Paul Newland, AD71 -- this 
paper presents an idea for verifying&that a user 
within a party line network is who he or she 
claims to be. The idea assumes that the channel 
is a party line and the potential intruders will 
monitor authorized communications and may attempt 
to masquerade as authorized users. No attempt is 
made to encrypt the authorized user’s data for 
transmission over the party line. 


“A More Watchful Watchdog for Microcomputers,” by 
Paul Newland, AD71 -- Many hardware/software 
watchdog timers consist of a software routine that 
repetitively triggers a hardware retriggerable 
monostable. If the monostable ever times out, the 
computer is reset. This technique, although 
useful, is not extremely reliable under most 
software/hardware insane conditions. This paper 
discusses an alternative approach that may prove 
to be more reliable under various fault 
cond it ions. 


You can see from these abstracts that many 
interesting papers will be presented at the 
conference (and published in the proceedings). 
Whether you are interested in learning more about 
packet-radio protocols, applications or equipment, 
you will be excited by the conference. If you 
think that you will be left behind by the 
technical papers, be sure to attend “Pete’s Packet 
Primer ," which will begin at 10:45 AM on March 
30th in room 232 (the same room that will house 
the rest of the conference). 


Details of the conference remain as stated in 
Gateway issue 14, with the following additions: 
On March 29th, beginning at 8:00 P.M., there will 
be a Network Management meeting at the San 
Francisco Pizzeria, 418 Beach Street. On March 
30th (the day of the conference) there will be an 
8:30 breakfast at Tad’s restaurant, 12 Powell St., 
and an 8:00 P.M. dinner at New Joe’s Restaurant. 
Dinner reservations will be taken during the 
conference. If you have any questions about the 
Amateur Radio Computer Networking Conference, 
contact Hank Magnuski at (415)-854-1927. If you 
have any questions about the Computer Faire 
itself, call (415)-364-4294. 


Via KA6M, Ed. 


SPECIAL CONFERENCE ISSUE_OQF_ GATEWAY 


Issue number 16 of_Gateway will be distributed at 
the West Coast Computer Faire and the Fourth ARRL 
Amateur Radio Computer Networking Conference. 
This will be a special issue, providing the casual 
reader with an overview of packet radio and 
current packet activity and a list of packet-radio 
clubs. Even if you think that we already have 
information on your club, contact Gateway to be 
sure that you are included in this special issue. 
Include é¢ description of any projects that your 
club is involved in. Remember, severa 1 hundred 
copies of Gateway number 16 will be handed out at 
the Faire, this is your chance to get some 


Leave the 
cali or 


for your club. 
write ARRL Headquarters. 


Ed. 


EMERGENCY COMMUNICATIONS 


Pattie Winter, N6BIS, will be writing a major 
article on the use of packet radio in emergency 
commun icat ions, and she is seeking information 
from anyone who has experience in this area. If 
you have written an article on this subject or 
done emergency planning which incorporates the use 
of packet-radio technology, please send a copy of 
the article to Patti at 


Patti Winter, N6BIS 
P.O. Box 537 
Menlo Park, CA 94026. 


Patti would also like to meet and interview anyone 
who has used packet radio for emergency 
communications. She will be holding interviews at 
the Fourth Amateur Radio Computer Networking 
Conference. 


From KA6M 


GEORGIA LIAISON 


The Georgia Radio Amateur Packet Enthusiast 
Society (GRAPES) now has a “packet-radio liaison,” 
responsible for sending out informat ion packages 
about packet radio and keeping other organizations 
up to date on packet radio in Georgia. People 
interested in the information package should send 
$1.00 and an s.a.s.e. to 


Bill Crews, WB2CPV 
1421 Hampton Ridge Road 
Norcross, GA 30093. 


From WB2CPV. 


HF ACTIVITY 


While there is considerable packet activity on the 
HF bands, it’s hard to say when or on what 
frequencies. To help ease this confusion, paving 
the way for more HF packet activity, Gateway, with 
the help of Pete Eaton, WB9FLW, is compiling a 
list of active HF packet stations, the frequencies 
that they use, and the times that they are most 
active. If you are on HF packet radio, send 
information about your activity to Gateway, at 
ARRL Headquarters. 


WB9OFLW, Ed. 


INTERMOUNTAINNETWORK 


Dave Peder sen, N7BHC, from Salt Lake City, Utah, 
will be travelling to Boise, Idaho, hoping to 
spread packet radio in the west. Dave thinks that 
the 30 or 40 interested hams in Boise could be 
linked to the growing network in Salt Lake City by 
midsummer. Rod Greeene, W/7Z2RC, in Boise feels 
that extending the link from Boise to Pullman, 
Washington and then to Seattle would be fairly 
easy. 


transmit timely forecast information from the 
Hurricane Center to effected areas. 


“Packet Radio for Distance Teaching in the Third 
World," by Phil Gray, KA7TWQ -- This paper 
discusses how packet radio could improve the 
interactive capabilities of “Distance Teaching” ( 
delivery of education to remote or sparsely- 
populated areas>. It also presents views on how 
packet radio could improve the delivery and 
efficiency of Distance Teaching in Less-Developed 
Countries. 


“EASTNET: A Year Later,” by Bob Bruninga, WB4APR 
-- The original goal of EASTNET to link the 
eastern seaboard from Washington, DC to Boston was 
met, more or less, on August 6, 1984, when packets 
were exchanged between Elk Neck, Maryland, and 
Lowell, Massachusetts. Since that time, numerous 
alternate paths have been exercised. The 
saturation of the primary link frequency of 145.01 
MHz during prime evening hours, however, has 
prevented routine end-to-end, multihop paths. 
This paper presents some methods of relieving this 
congestion. 


“Activity Report of [Japan’s] PARNET," Yamazaki, 
et al -- We have been studying and working on 
digital communications in ham radio for the past 
year. The group’s activities are described in 
this paper. In section one, there are members’ 
profiles, the group’s objectives and the results 
of our investigations. In section two, the 
hardware of the prototype PARNET TNC is described. 
In section three, the TNC software is described, 
and prospects for the future are presented. 


“Formal Definition Meeting for the Packet Radio 
Experiment (RUDAK) to be Included in AMSAT P3-C," 
by Karl Meinzer, DJ4ZC and Hans Peter Kuhlen, 
DK1YQ - - During the weekend February 15 through 
17, AMSAT-DL hosted a formal meeting to define the 
packet payload in F3-C. The experiment has been 
named “RUDAK” for “Regenerativer Umsetzer fur 
Digitale Amateur-Kommunikation” [Loosely: 
“regenerative transponder for amateur digital 
communication.” -- Ed.]. This paper presents the 
resulting design, inc lud ing link budgets, 
modulation schemes, and bit rates. 


“Of Virtual Circuits, Datagrams, and the Circular 
File,” by Terry Fox, WB4JFI -- Even as work was 
being completed on the link layer, amateurs were 
beginning to take on the challenge of designing a 
true amateur packet network. Two “camps” have 
taken shape in this stage of development work: the 
“virtual circuit” camp and the “datagram” camp. 
This paper presents a slightly biased view of 
these two camps and their protocols. 


“FADCA GATOR LINK 1 Packet Radio Linking Network,” 
by Howard Goldstein, N2WX and Ted Huf, K4NTA -- 
The GATOR LINK 1 concept was devised in the summer 
of 1984 by a group of members of the Florida 
Amateur Digital Communications Association (FADCA) 
as a method of linking packet-radio digipeaters 
into a system that would provide wide-area 
communicat ions without the problems involved in 
single-frequency digipeat ing. It was recognized 
that, while AX.25 Level 2 provided a means of 
linking digipeaters, as packet radio activity 
grew, it would become more difficult to use this 
feature because of collisions. The GATOR LIN 1, 
as described in this paper, provides a solution to 
this problem. 


“Communications Protocols for the Network and 
Transport Layers of the Amateur Packet Network,” 
by Gordon Beattie, Jr., N2DSY -- There has been 
much discussion among amateurs about 
internetworking with other areas of the country 
and globe. This has lead to introduction of terms 
into the vocabulary of many amateurs, many of whom 
are newly equipped with computers! In this paper, 
we will present the IS0/CCITT Open Systens concept 
and its impact on the protocols that we wish to 
use to provide reliable data transfer in the 
amateur network. In order to provide a basis for 
contrast, we will also introduce the U.S. 
Department of Defense model of communications 
systems. 


"TCP/IP: A Proposal For Amateur Packet Radio 
Levels 3 and 4,” by Phil Karn, KA9Q -- This paper 
presents a case for basing Level 3 (the network 
layer) of amateur packet radio on the “datagram” 
concept. It further proposes that the DARPA 
protocols IP (Internet Protocol) and TCP 
(Transmission Control Protocol) be adopted intact 
as the standard Level-3 (Network) and Level-4 
(transport) protocols for Amateur Packet Radio. I 
will then provide an overview of TCP/IP, explain 
why it, as a datagram protocol, is more suitable 
for our needs than the virtual-circuit protocol 
CCITT X.75, and show how it would be used above 
the AX.25 Level-2 protocol already in use. 


“Addressing and Routing Issues in Amateur Packet 
Rad io," by Phil Karn, KA9Q -- As amateur packet 
radio evolves from scattered, ad-hoc collections 
of local digipeaters into a large, automatic and 
interconnected network, several issues related to 
naming, addressing and routing will have to be 
faced and overcome. Routing, in particular, has 
long been a fertile research area in computer 
networking. I make no claim to knowing the 
answers to many of these problems; however, I 
believe that they can at least be stated, and that 
certain decisions can be made early to ease 
experimentation with various solutions. In 
particular, the problem of address assignment is 
discussed with particular emphasis on making the 
rout ing problem easier. 


“Proposal: Recommendation AX.121NA, a Numbering 
Plan for the Amateur Radio Network in North 
America,” by Gordon Beattie, Jr., N2DSY -- The 
purpose of this numbering plan is to facilitate 
the introduction of amateur data networks and 
provide for internetworking in North America. 


“CCITT X.244 Transport Layer Protocol Basic 
Description,” by Terry Fox, WB4JFI -- In order to 
assure absolute data integrity through the amateur 
network, some form of transport-layer protocol 
should be employed between the entry and exit 
points of the network. This paper proposes the 
use of another CCITT X-series protocol to correct 
for potential deficiencies in AX.25 Level 3. 


“X.3 and X.28 Protocols for Terminal Node 
Controllers,” by Douglas Lockhart, VE7APU -- This 
paper proposes the adoption of an extended version 
of CCITT recommendations X.3 and X.28 for use in 
amateur-radio terminal node controllers (TNCs). 
The various X.3 parameters and X.28 commands and 
service signals (messages) are outlined and the 
extensions in place in the V-2 software 
implementat ion on the Vancouver Amateur Digital 
Communication Group (VADCG) TNC are discussed. 


Gateway yt te 
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PACSATMEETING 


I had the good fortune to attend the design 
meeting for PACSAT held recently in Rosslyn, 
Virginia. At this meeting, representatives of 
AMSAT, the Volunteers In Technical Assistance 
(VITA) and NASA discussed the details of PACSAT 
funding, design and construction. 


The most important issue discussed at the meeting 
was funding. Like all amateur satellites, PACSAT 
will be inexpensive, but sources of major funding 
will still have to be identified. PACSAT 
represents a unique opportunity for funding 
organizations to take part in a technological 
experiment that is also a social experiment; 
PACSAT, if successful, will prove that low-orbit 
data-communications satellites can be used to 
coordinate development and relief efforts in 
Third-world countries. Of course, PACSAT will 
also increase the utility of amateur packet radio 
by providing world-wide packet forwarding. If 
your group would like to contribute to PACSAT, or 
if you can help identify sources of major funding, 
contact 


Dr. Gary Garriott 

VITA PACSAT Project Officer 
1815 North Lynn Street 
Arlington, VA 22209. 


After discussing funding, the group concentrated 
on technical considerations. Operators will see 
PACSAT as a packet bulletin board system (PBBS) in 
low-earth orbit. The PBBS will have somewhere 
between 2 and 4 megabytes of memory, and you will 
be able to access the satellite with an AX.25 TNC 
and some special radio/modems. This is all 
relatively straightforward, when compared to other 
aspects of PACSAT’s design. AMSAT and VITA hope 
to have PACSAT launched as a Getaway Special (GAS) 
payload on the space shuttle. Such a launch 
places complex constraints on PACSAT’s size, 
shape, propulsion system and construct ion. PACSAT 
must fit in a standard “GAS can” which is only 19 
inches in diameter and 20 inches tall. Fitting 
several megabytes of memory, spacecraft 
controllers, transmitters, receivers, batteries, 
and a propulsion system into less than 5 cubic 
feet will be quite a job. To protect the shuttle 
and its crew, PACSAT will have to go through 
safety and construction tests more complex than 
AMSAT has ever confronted. The successful 
construct ion, launch and operation of PACSAT will 
depend on and demonstrate the best that Amateur 
Radio has to offer. That this is also a packet- 
radio project makes it of interest to all Gateway 
readers. 


Ed. 


PACKETPAPERS. 


Several more papers for the Fourth ARRL Amateur 
Radio Computer Networking Conference have arr ived. 
Here are the abstracts for those papers: 


“The Frequency Agile Message System (FAMS)," by 
Dave Borden, K8MMO -- With the increasing traffic 
appearing on local-two meter packet radio 
channels, computer message systems appear to the 
casual conversationalist as channel hogs. The 
message systems interfere in two modes; First, a 
typer user connects with it and downloads large 
packets of data, help messages and directories. 
Second, a semi-automatic store-and-forward mode is 
invoked periodically to forward messages to other 
systems further up the network. The service that 
these message systems provide more than justifies 
their existence, so the answer is not to ban them. 
New operating practices might alleviate the 
interference and retain the useful features of the 
bulletin board systems. This method involves 
frequency agility -- the ability to change 
frequencies on command. 


“Packet Radio Development =- 1985,” by Lyle 
Johnson, WA7GXD -- A review of packet growth since 
the Third ARRL Networking Conference is followed 
by a discussion of anticipated expansion of packet 
activity during the next year. A framework for 
orderly growth is presented, based on the above 
observations. 


“The Realities of Packet Radio in the Amateur 
Radio Service, circa 1985, or How to Deal with a 
User Base ," by Harold Price, NK6K -- The author 
postulates the existence of two major experimenter 
groups in amateur packet radio: those who 
experiment with data sent via packet radio and 
those who experiment with the way data is sent via 
packet radio. The problems of these groups in the 
face of 5000 or more packet users by the time of 
the 5th ARRL Computer Networking Conference are 
discussed. 


“The Implications of Traditional Operzting 
Practices for Amateur Packet Network Design,” by 
Gwyn Reedy, WIBEL -- Amateur packet network design 
relies heavily upon equipment and procedures 
developed for commercial service. This paper urges 
network designers to examine the anticipated 
amateur uses of the network and modify commercial 
practice to accommodate the existing amateur 
population. 


“Packet Radio and the National Hurricane Center,” 
by Joel Kandel, KI4T -- Amateur Radio operators in 
South Florida are exploring the ability of packet 
radio to provide the National Hurricane Center 
with high quality weather observations and then to 


HAMNET is a well-run discussion of all topics in 
Amateur radio. Section 9 in HAMNET is devoted 
exclusively to packet radio, RTTY, and AMTOR. 
Messages and news items for Gateway can be 
directed to CompuServe account #75105,737. 


Ed. 


RMPRA POWER SUPPLY DATA 


Not all of the surplus power supplies that are 
“just like the Radio Shack” are suitable for 
conversion to power TAPR TNCs. To be safe, buy 
only the supplies specified in the Rocky Mountain 
Packet Radio Association (RMPRA) documentat ion. 
This documentation is available from RMPRA for an 
S.a.s.e. to: 


RMPRA Power Supply Experiment 
3775 East 115 th Ave. 
Thornton, CO 802338. 


Ed. 
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“Computer Networking in Japan...,” by Robert 
Richardson, W4UCHK -- The evo lut ion, deve lopment , 
and implementation of the Microsoft MSX operating 
system in nearly 2 dozen models of microcomputers 
now being manufactured in the Far East and Pacific 
is discussed. The paper also addresses the impact 
of these MSX computers on packet radio on the 
amateur bands, primarily in Japan, for 1985 and 
onward. 


“AX.25 Net Operation in the Connected Mode Using 
the Software Approach,” by Robert Richardson, 
W4UCH -- This brief paper presents the means 
whereby an amateur radio net may be conducted 
using the AX.25 packet protocol with all stations 
in the connected mode. Use of a net control 
station connected simultaneously to all members of 
the net is described. The paper also discusses 
window overlays on video displays of all members 
of the net to display other net members’ packet 
informat ion fields. 


If you have written a paper for the conference, 
the deadline has passed, rush your paper to Marian 
Anderson, WAIFSB, at ARRL Headquarters. 


Via KA6M, Ed. 


PUBLICITY IN JAPAN 


The January 1985 issue of CQ HAM RADIO, a thick, 
glossy Japanese ham radio magazine, contains a 2- 
page spread covering the TAPR TNC. The article, 
written by JH3XCU, mentions TAPR, VADCG and AX.25. 
Considering the fact that this magazine has a 
circulation of 500,000, this article should 
stimulate signif icant interest in packet radio. 


From W3IWI. 


XEROX 8208 


You may have noticed that a lot of packet-radio 
software has been developed for the Xerox 820 
computer. These computers have become a favorite 
of the U.S. packet community. Now they are 
spreading throughout the world. Miki Nakayama, 
JRISWB, coordinator of the packet portion of the 
JAS-1 satellite project, has a couple of Xerox 
boards, and he intends to run the WORLI MailBox on 
one of them. ZLIAOX, in Aukland, New Zealand is 
also using a Xerox and the WORLI software. 


[The Xerox 820 is a Z80 computer with 64 kbytes 
of RAM, on-board video, and serial and parallel 
1/0. Best of all, the boards are usually 
available from the Xerox Outlet for less than 
$100. Call the Xerox Outlet (persistently) at 
(214)-960-3367. -- Ed.] 


From W3IWI. 


SOFTWARE TNCS 


People getting interested in packet radio often 
ask, “Why can’t I program my computer to be my 
TNC?" The answer is, “You can.” Bob Richardson, 
W4UCH, has had packet-radio software for the TRS- 
80 computers for several years, and it works quite 
well. There are two reasons that groups like 
VADCG and TAPR designed and distributed dedicated 
TNCs. First, adedicated TNC can be used with any 


computer that has a serial port, whi.:e a program 
implementing a packet radio node will probably 
only run on a single type of computer. The second 
reason for using dedicated TNCs is that they leave 
the station computer free to run applications 
programs that use the TNC J] ike a modem. 


The “software approach” to packet radio is, 
however, a valid and useful approach, any hams 
who are unwilling to buy TNCs would try packet 
radio if all they had to do was enter and run a 
program. So, if you are considering writing 
packet-radio software for some computer, go to it! 
Remember, though, that implementing the AX.25 
protocol is a major project, and in order to be 
useful, a program must implement the whole 
protocol correctly. To avoid problems, be sure to 
work from a up-to-date specification of AX.25, 
Version 2.0. This specification is available from 
the ARRL for $8.00. 


We know of packet software projects for the Vic-20 
and the Apple 11 computers. If you know of other 
efforts that are under way, send a note to 


Gateway. 
Ed. 


INTERFACE COLLECTION 


The following message is forwarded from Lyle 
Johnson, President of Tucson Amateur Packet Radio 
Corporation: 


“I am compiling a list of hardware and software 
that can be used by a computer neophyte to 
interface to a TNC, such as the AEA, GLB, 
Heathkit, TAPR or VADCG TNCs. 


“I am especially interested in what cables are 
needed, other than the simplest form of RS-232 
with DB=-25 connectors at each end. 


"I would also like to know about any simple, cheap 
or public domain terminal programs available. The 
idea is to make it as painless and cheap as 
possible for a packet newcomer to get on the air. 


“It is particularly important that I get 
information about the following computers: 


Commodore Vie-20 and C64 

IBM PCjr and PC 

Radio Shack TRS80-1,-3,-4 and CoCo 
Apple II, II+, //e, //¢ and Macintosh 
TI 99/4 and 99/4A, 


"Any listings of simple, dumb terminal programs 
and sources of cheap commercial programs are also 
welcome . " 


From WA7GXD. 


COMPUSERVE HAMNET 


If your interest in data communications is 
growing, and you would like to take part in a 
continuing discussion of issues in packet radio, 
consider joining HAMNET on CompuServe. If you are 
already on CompuServe, type “GO HOM 11" to get to 
HAMNET. If you would like to get on Compuserve, 
contact a local computer store and ask about it. 
CompuServe connect fees are reasonable, and the 


stations on VHF, he has been doing a lot of 
operation on HF. There is, of course, talk of 
linking Charleston and Morgantown. So, if you 
live on a hilltop in West Virginia, look for 
WB8CQV, N8BHI and K8LG on packet radio. 


From WBS8CQV. 


ACTIVITY IN NEWYORK 


There is a growing packet-radio group in 
Rochester, New York. The city has about 12 active 
stations, and 12 more interested parties. Most of 
the stations are using GLB PK-1 TNCs. Rochester 
is an interesting area from which to pursue east~ 
west linking efforts; with a little effort 
Rochester could be connected to the Midwest and to 
EASTNET, beginning a transcontinental link. 


The Rochester group (which has no formal name) has 
been recruiting amateurs from the ranks of the 
local computer clubs. This is a good idea for all 
packet-radio groups. Give a demonstration of 
Amateur packet radio to a local computer club; 
computer hobbyists may be surprised to find that 
amateur radio has something to offer them. As 
well as helping your packet club grow, these 
computer-oriented amateurs can be an asset to all 
of amateur radio. : 


To contact the Rochester packet radio group, 
send a letter to: 


Fred Cupp, W2DUC 
27 Crescent Rd. 
Fairport, NY 14450. 


Prom W2DUC. 


PACKET RADIO IN PHOENIX 


While those of us with TAPR TNCs tend to think of 
Arizona as a hotspot of packet activity, local 
networks have been slow to get started there. 
Dean Norris, K7NO, recently sent Gateway a report 
on activity in the Phoenix, Arizona, metropolitan 
area. Dean and Wes Morris, K7PYK are both active 
on HF packet. Wes, in Scottsdale, Arizona, is 
running a WORLL MailBoxon VHF and HF, providing 
a route for traffic into and out of the area. 
There are a few other stations that are active 
only on VHF. 


Dean and Wes are interested in optimizing filters 
and modems for HF packet. Dean has observed that 
there is a critical range of IF and audio 
filtering which yields acceptable results under 
various noise and interference conditions. Wes is 
looking for packet operators who have experimented 
with the Yaesu FT-980 on packet. If you are 
interested in HF packet radio, listen on 14.100 
MHz and 10.147 MHz. All stations are using 300- 
baud transmission rate and 200-Hz shift. 


From K7NO. 


NETWORK NOTES 


Here are some other short notes on Amateur packet 
activity: 


Alabama -- The Birmingham packet network is the 
focal point of packet traffic handling by Navy- 
Marine Corps MARS. This network is being 
coordinated as part of the Navy-Marine Corps Mars 
High-Tech program, under the guidance of Jim 
Gr if ith, WA5RAX. 


Georgia -- Macon is getting a packet repeater, and 
the path from Atlanta to Jacksonville (Florida) is 
getting better every day. 


Illinois -- The Chicago Amateur Packet Radio 
Association (CAPRA) has formed a Level-3 Software 
Development Group. This group is investigating 
ways to provide high-level linking to the Chicago 
area. The effort will center around the 9600- 
bit/s, 220~MHz modems developed by CAPRA member 
Steve Goode, K9NG. 


Ontario -- There is an AX.25 packet network taking 
shape in the Hamilton area. Jim Symes, VE3NBN, 
reports that there are already 4 nodes on the air, 
with a digipeater soon to be operational on 145.01 
MHZ. 


Via DRNET, HAMNET. 


FOURTH ARRL NETWORKING CONFERENCE 


Here is some more information about the Fourth 
ARRL Amateur Radio Computer Networking Conference, 
to be held in San Francisco, California, on March 
30. 


All technical sessions for the conference will be 
held in room 232. This room is in the East Wing 
of the Moscone Convention Center. Here is a new 
schedule of events for the conference: 


1030 = Opening remarks and keynote address by Paul 
Rinaldo, W4RI . 

1045 = Pete’s Packet Primer by Pete Eaton, WB9FLW. 

1130 = Papers on packet-radio applications. 

1200 = Panel session on packet-radio applications 
by Andy Cromarty, N6JLJ. 

1230 = Lunch Break. 

1330 = Papers on digital communications and packet 
radio . 

1800 = End of technical papers. 


If you are a newcomer to packet radio, be sure to 
attend the Packet Primer. This session should 
prepare you for the technical papers that will be 
presented later in the conference. 


The voice coordination frequency for the 
conference is 146.19/.79 MHz, linked to 
443.1/448.1 MHz. This repeater, WB6FDT/R is being 
provided courtesy of the Telephone Pioneers. 


To whet your appetite for the conference, here are 
the abstracts for some of the papers that will be 
delivered: 


“Packet Radio Timing Considerations,” by David 
Engle, KE6ZE -- This paper presents an analysis of 
existing packet radio systems and equipment (2 
Meter AFSK). Both dual- and single- frequency 
repeater efficiencies are analyzed. The results 
demonstrate the relative inefficiencies of the 
existing networks. These inef f ic ienies reduce the 
effective capacity of a 1200~-baud channel to 300- 
500 baud. In order to correct some of these 
inefficiencies a few suggestions are offered. 


Gate Weal ats 
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REPEATER BAN LIFTED 


On February 21, the FCC released an Order 
rescinding the repeater moratorium originally 
declared in Paragraph 10 of the Notice of Proposed 
Rulemaking, PR Docket 85-22. The Commission 
stated that “filings by the American Radio Relay 
League (ARRL) and by the Tri-State Amateur 
Repeater Council (TSARC) raise serious 
difficulties with the imposition of the 
moratorium, including f inanc ia 1 hardship to those 
with repeater construct ion in process. The 
problems persuade us to rescind the moratorium. 
Instead we will seek a permanent solution to all 
issues relevant to solving questions of 
interference and congestion by and to stations in 
repeater operation.” 


So, packet networks can continue to grow. 
Repeater coordination and packet networking are 
still important topics. The FCC requests 
“substantive comment on all issues relevant to 
solving questions of interference and congestion 
by and to stations in repeater operation.” This 
includes packet repeaters. If you or your Network 
Coordinating Agent (NCA) have opinions on the 
question of repeater coordination, be sure to 
bring those opinions to the attention of the FCC. 


via W1UED, ED. 


CENTRAL NEW ENGLAND COORDINATION 


There is some confusion about the proposed Tri- 
State Packet Radio Council (TSPRC). People have 
been confusing TSPRC with TSARC, the Tri-State 
Amateur Repeater Council. TSPRC is not affiliated 
with TSARC, and at the first meeting of the packet 
radio council, a name change will be discussed. 
The name of the packet radio council is similar to 
that of the repeater coordinating council because 
the packet radio council intends to cover the same 
area as TSARC. This area inc ludes Connect icut, 
Northern New Jersey, Long Island, New York City, 
and Dutchess and Orange counties in New York. All 
packet-radio clubs in this area are invited to 
join the Network Coordinating Council. The first 
meeting of the council will be in conjunction with 
the Trenton Computer Fest, April 21, in Trenton, 
New Jersey. 


Ed. 


TEXAS FREQUENCY COORDINATION 


On February 16, the Texas VHF-FM Society 


membership passed a motion approving packet radio 
operations on 145.01, 145.08, 145.05, 145.07, and 


145.09, 223.56, 223.58, 223.60 and 441.0 MHz. The 
Society could not decide whether it should 
coordinate wide-area digipeaters. The 220.5 to 
221.3 MHz section of the 220-MHz band is heavily 
used in the Dallas area. It is possible, however, 
that one 100-kHz channel in this section of the 
band will be coordinated to facilitate out-of- 
state linking. 


From WA5MWD. 


440-MHz PACKET 


Although not a lot of attention has been paid to 
packet operation in the 70-cm band, several 
frequency coordinating bodies have coordinated 
packet channels on this band. Bill, KB2CQ, 
reports that he has a GLB PK-1 digipeater on 
441.000 MHz in Queens, New York. If you are 
active on 70-cm packet radio, send a report to 


Gateway. 


In a recent issue of Gateway we incorrectly 
reported the 70-cm frequency coordinated for 
packet radio in Northern California. The packet 
channel is 441.500 MHz. 


via KB2CQ, NI6A. 


CINCINNATI PACKET CLUB 


Cincinnati, Ohio, now has its own packet-radio 
group. The group, called the Cincinnati Amateur 
Packet Radio Experimenters Society (CAPERS), was 
formed after a packet forum at the Cincinnati ARRL 
convention, February 23. Although there are no 
packet stations on the air in Cincinnati, several 
of the group members have TNCs on the way. The 
group’s first task will be to establish a link to 
the active packet network in Columbus. To contact 
CAPERS, write: 


John Schroer-IV, KA8GRH 
984 Halesworth Drive 
Forest Park, OH 45240. 


Ed. 


WEST VIRGINIA PACKET 


The packet network in West Virginia is growing. 
John Jones, WB8CQV, recently sent us a message via 
the WORLI HF MailBox. John, in Charleston, says 
that he knows of two other packet stations, both 
in Morgantown. Although John can’t reach these 


CORRECTION 


In the item "12-V DC SUPPLY FOR TNCS" in Gateway- 
number 12, there were two errors. The list of 
those who developed the power supply should 
include Don Brown, N@BRZ, and the item should be 
attributed to NOCCZ, not NOCCX. Sorry about that. 
The power supply was on display in Tucson, and it 
looked like a simple, useful project. 


Ed. 
PACKETAT HAMFESTS 


There will be packet-radio booths or forums at the 
following upcoming hamfests: 


Feb. 23 -= Midwinter Technology Fair, Fridley, 
Minnesota. Talk-in frequency 147.$0/.66 MHz. 


Feb. 23 -- ARRL Ohio State Convention, Cincinnati, 
Ohio. Packet forum at 1:69 PM. 


REPRODUCTIONOF GATEWAY MATERIAL 


Material may be exerpted from Gateway without 
prior permission, provided that the original 
contributor is credited and Gateway is identified 
as the source. 


Gateway: The ARRL 

Packet Radio Newsletter 
American Radio Relay League 
225 Main St. 

Newington, CT 06111 


published by the 


American Radio Relay League 
225 Main Street 
Newington, CT 06111 


Jeffrey W. Ward, K8KA 
Editor 


Larry E. Price, W4RA 
President 


David Sumner, K1ZZ 
General Manager 


Subscriptions are available to ARRL members and 
nonmembers, at the following rates: 


For 25 issues of Gateway: 

In the U.S. 
ARRL Member $6 .0O 
Nonmember $9 .00 

In U.S., Canada, and Mexico by First Class Mail 
ARRL Member $11.00 
Nonmember $14.00 

Elsewhere by Airmail 
ARRL Member $14.00 
Nonmember $17.00. 


Prices are subject to change without notice. 
Remittance must be in U.S. funds, and checks must 
be drawn on a bank in the U.S. 


Nonprofit Organization 
U.S. Postage 

PAID 

Hartford, Conn. 
Permit No. 2929 


SOUTHERN WESTNET COORDINATION 


The packet-radio community in Southern California 
has formed the Southern California Digital 
Communications Council (SCDCC). The purpose of 
this council is similar to that of groups 
previously formed in Northern California and the 
Mid-Atlantic States: to provide a single point of 
contact to the area frequency coordinating bodies 
and to serve as a clearing house for information 
and a forum for discussion of effective use of 
network resources. The first act of SCDCC was to 
petition the local two-meter coordinating body for 
allocation of 145.01 MHz as an inter-region packet 
linking frequency. 


Membership in SCDCC is open to anyone with an 
interest in digital communication. All California 
packet-radio operators from Santa Barbara to the 
Mexican border are encouraged to join. The SCDCC 
mailing address is: 


SCDCC 
P.O. Box 6426 
Mission Hills, CA 91345. 


Via NK6K. 


FREQUENCIES — COORDINATED 


The New England Spectrum Management Committee met 
on January 26, 1985 and made the following 
frequency allocations for packet radio: 


2 meters: 145.01 to 145.09 MHz, for operation with 
less than 5 kHz deviation. 


11/4 meters: 5 19$$-kHz channel6 between 220.5 and 
221 MHz and 1@ 2G-kHz channel6 from 221.G@ to 
221.18 MHz. 


70 cm.: 19 1$$-kHz channels from 434% to 431 MHz 
and a single frequency at 441.00 MHz for 5~-kHz 
deviation operation. 


This allocation scheme follows a plan discussed at 
the Third ARRL Amateur Radio Computer Networking 
Conference and published recently in the 
newsletter 220 NOTES. 


In Florida, the Florida Repeater Council has 
coordinated 145.01 MHz as the state-wide packet~- 
radio frequency. In add it ion, they have 
coordinated 221.72, 221.78 and 221.40 MHz as 20@- 
kHz channel6 and 229.57 for 199~kHz bandwidth 
operation, 


Via K4NTA and AGIF. 


NTS AND PACKET RADIO 


Don Haney, KAIT, is running a packet-radio 
bulletin board system (PBBS) dedicated to NTS 
traffic. Don’6 PBBS guides users who are 
unfamiliar with NTS radiogram format through the 
message originat ion process. The PBBS is part of 
the growing network of W@RLI MailBoxes that are 
forwarding traffic around New England on 145.01 
MHz. Don is looking for stations on HF to extend 
this network. 


In the January issue of the NEPRA Packetear, Don 
writes that 110 pieces of formal NTS traffic went 


through his PBBS in December. Forty-five percent 
of that. traffic was for delivery outside New- 
England and 35% was between the Eastern and 
Western Massachusetts. The balance of the traffic 
was for delivery in New Hampshire, Connecticut and 
Eastern Massachusetts. 


If packet traffic is originated on a crowded 
channel or entered by keyboard, each message takes 
about 3 to 5 minutes -- longer than it would take 
to originate the same message on FM or CW. The 
advantages of packet radio are realized when the 
messages are being forwarded from computer to 
computer automatically. With automatic 
forwarding, messages can be passed at times that 
would otherwise be inconvenient, and they can be 
passed without introduction of errors. 


VIA PACKETEAR. 


MODEMS AVAILABLE 


Jerry Quimby, N4AJH, is making available a limited 
number of PC boards for EXAR modems. Jerry is 
selling a finished PC board, parts placement 
diagram, parts list, schematic diagram and tune-up 
instructions. The PC board measures 1 1/2 by 3 
in., and can be used for either 3$@-bit/s or 12@6- 
bit/s AFSK operation. If you are interested, send 
$8.50 in check or money order to: 


Jerry Quimby, N4SAJH 
2677 Hereford Rd. 
Melbourne, FL 32935. 


These modems are already in service on some 
heavily-used Florida digipeaters, and the chips in 
the circuit are the same ones used in all of the 
available TNCs. Even though you must supply your 
own parts for the PC board, this is an inexpensive 
modem. 


VIA DRNET. 


TWO-PORT DIGIPEATER 


If you want to link two packet networks that are 
on different frequencies, you may have to use 
complex digital and audio contraptions. Most of 
the available schemes involve auxiliary links 
between digipeaters on different frequencies, or 
single digipeaters that use audio mixing to 
communicate simultaneously on two channels. While 
these solutions to the frequency-translation 
problem work, they are not always the simplest or 
most efficient solutions. 


A simple solution to this problem is a digipeater 
with two independent packet I/O ports and enough 
internal logic to route packets from one port to 
another. Jon Bloom, KE3Z, has written a program 
that implements such a digipeater. The software 
runs on a Xerox 82G@, using the serial I/O port 
(SIO) to send and receive packets. It has several 
mechanisms for routing packets from one port to 
another. The program resides in ROM, and is 
suitable for remote digipeaters. 


If you are interested in this software, send an 8” 
SSSD disk to Gateway. In return, you will receive 
the program and appropriate documentation. 


Ed. 


On February 2nd, packet-radio operators from 
Northern New Jersey, Eastern New York and 
Connecticut met to discuss the formation of a 
Network Coordinating Agent (NCA). Those present 
agreed to form a NCA called the Tri-State Packet- 
Radio Counc il (TSPRC). TSPRC will be a council of 
packet radio clubs from the areas covered by the 
Tri-State Amateur Repeater Council (TSARC), a 
frequency coordinating body. All clubs within 
TSARC jurisdiction are invited to attend the 
init ial meeting of TSPRC, at the Trenton Computer 
Fest, April 21st. For further information on 
TSPRC, contact: 


TSPRC, c/o Jeff Ward, K8KA 
52 Alden St., Apt. 292 
Hartford, CT 06114. 


Kd. 


HEATHKIT TNC 


Those lucky enough to attend either the Miami 
Eamfest or the TAPR Annual Meeting have seen the 
second entry into the “TAPR-clone" field. The 
Heathkit HD-494@ is a TAPR TNC in a brown and 
beige low-profile cabinet. Status-indicating LEDs 
are grouped on the left side of the front-panel, 
and the only switch on the unit is an ON/OFF 
switch on the right side of the panel. Inside, 
the HD-494@ is purely a TAPR TNC, complete with 
modem-configuration headers and AC power supply. 
The kit will sell for $299.99 and should be 
available by the second week in April. 


The kit will feature an “improved” TAPR manual. 
Considering that the TAPR manual is one of the 
best seen in amateur radio, the Heathkit manual 
should be a superb document. Parts for the HD- 
4649 will come on an adhesive strip, in the order 
that they are required in kit construction. This 
packaging technique makes parts-list checking 
unnecessary, and should make construction go quite 
quickly. 


The HD-4949 will bring two new marketing 
techniques to Heathkit: For the first time, the 
Heathkit TNC manual will explain how to connect a 
Heathkit accessory to non-Heathkit radios. Also, 
Heathkit will probably be selling the HD-494@ in a 
specially-priced package with another 
manufacturer’s assembled and tested amateur radio 
transceivers. 


Wayne Wilson, Heathkit’s Product Line Manager for 
General Consumer Products, attended the TAPR 
meeting. Mr. Wilson believes that packet radio 
could breath life into the sagging amateur-radio 
industry. Heathkit is eager to build connections 
between amateur radio and computers, hoping that 
technically-inclined youth can be drawn back into 
amateur radio. 


TAPR will continue to produce the TNC kit as long 
as there is demand for them. Most of TAPR’s 
research and development funding comes from TNC 
sales. TAPR made the TNC available to commercial 
interests believing that packet radio is a field 
with room for more than one manufacturer. With 
nearly 2694 TAPR TNCs sold, they are being proven 
right. 


Ed. 


FOURTH COMPUTER NETWORKING CONFERENCE 


The Fourth ARRL Computer Networking Conference 
will be held in San Francisco on March 3$th, 1985. 
The conference, co-sponsored by the ARRL and the 
Pacific Packet Radio Society, will be held in 
conjunction with the Tenth West Coast computer 
Faire, which runs from March 3@th through April 
2nd at the Moscone Convention Center. The 
tremendous growth and interest in packet radio 
terminals, equipment, networks and applications 
promises to make this conference one of the 
largest and best-attended ever. 


The conference schedule for Saturday, March 30th 
follows: 


1000 = Introduction to Packet Radio 

1166 = Panel session on Applications of Packet 
Rad io 

1246 + Lunch Break 

1369 = Technical papers delivered 

1869 - End of technical session 

2960 = Conference dinner (price and location 
to be announced later). 


Through special arrangements with the Faire and 
the ARRL, a special pre-registration fee of $29 
will purchase a four day ticket to the Faire and 
the ARRL conference proceedings. Send a check for 
$26 and a s.a.s.e. to: 


Hank Magnuski, KA6M 
311 Stanford Avenue 
Menlo Park, CA 94925. 


The deadline for submitting papers for the 
conference proceedings is March lst, 1985. If you 
need an author’6 kit, contact the ARRL. 


Via KA6M. 


WESTNET LINKED 


The first reliable, 24-hour link between Northern 
California and Southern California was completed 
on February 8. In an amazing burst of energy, 
several digipeaters in Northern California were 
brought up in the last few weeks, extending the 
network 2@@ miles south. Coincidentally, a 
critical mountain range near Santa Barbara had 
just been bridged by amateurs from Southern and 
Central California. Until 145.01 MHz is allocated 
in Southern California, an audio link on 45¢ MHz 
connects the 145.@1-MHz digipeater at Arroyo 
Grande with the 145.35-MHz machine at Santa 
Barbara. Eventual removal of this audio link will 
make the Los Angeles to San Francisco path a 
three-digipeater connection. Now, stations from 
San Francisco can use a six-digipeater path to 
connect with Los Angeles. For packet operators in 
California, the completion of this path is a 
milestone and an indication of better things to 
come. 


For those keeping track of packet-radio DX 
records, the link between Northern and Southern 
California is approximately 539 miles long, and 
will be extended north another 1$@ miles soon. 


Via NK6K, KA6M. 
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TAPR MEETING 


I have just returned from the Annual Meeting of 
the Tucson Amateur Packet Radio Corp. (TAPR). 
Most of the “hotbeds” of U.S. amateur packet radio 
activity were represented at this day-long forum 
in Tucson. It was an exciting meeting: Several 
maps showing packet activity throughout the U.S. 
illustrated that packet radio is indeed growing 
rapidly. Last year, most people were worrying 
about stimulating packet activity in isolated 
areas; this year, the emphasis was on linking 
these isolated areas into a network. There were 
representatives from AEA and Heathkit, two of the 
commercial manufacturers who have “joined the 
packet-radio revo lut ion.” Perhaps the most 
exciting items demonstrated at the meeting were 
the 9.6-kbit/s modem6 designed by Steve Goode, 
KONG. With these modems transmitting data eight 
times as fast as current modems, a truly multi- 
level network can be built. (In such a network, a 
high-speed inter-city link would handle long-haul 
traffic for several 129@-bit/s conversations.) 
That TAPR has supported and organized these 
projects proves that the group responsible for the 
most popular TNC is still helping advance the 
amateur-radio state of the art. 


One of the purposes of the amateur radio service, 
as stated in Part 97 of the FCC rules and 
regulation6 is to “contribute to the advancement 
of the radio art.” Unfortunately, for many years, 
commercial technology has been advancing more 
quickly than amateur radio. Presentations at the 
TAPR meeting, made it clear that amateur packet 
radio is advancing the state of the radio art. 
Both the U.S. Forest Service and Army MARS sent 
representatives to the meeting to find out how 
they could use amateur-generated packet-radio 
techno logy. Several speakers mentioned that their 
local Red Cross emergency operation center6 are 
equipped for packet radio. In the west, where 
search-and-rescue efforts must cover vast areas of 
wilderness, the Civil Air Patrol has begun to use 
packet-radio for search coordination. TAPR TNCs 
have even found their way onto military hurricane- 
investigation airplanes. Amateur6 are once again 
contributing to the state of the art. 


The TAPR meeting reinforced my belief that packet 
radio is bringing out the best in amateur radio. 
The technological advances demonstrated at the 
meeting and the interest in packet radio shown by 
Heathkit and AEA lead those present to conclude 
that packet radio will enjoy rapid growth in the 
month6 and years ahead. 


Ed. 


Vol. 1, No. 13 
Feb. 12, 1985 


PACKET AND THE FCC 


In late January, the FCC released Notice of 
Proposed Rulemaking (NPRM) 85-22, proposing to add 
definitions of “coordinated repeater,” “frequency 
coordinator ," and “harmful interference” to 
Section 97.83 of the FCC rules and regulations. 
The NPRM also proposes adding text to Section 
97.85 concerning resolution of conflicts between 
repeaters. Complete text of this NPRM is 
available from the ARRL for an §.a.8s.e. with $0.54 
postage. 


In a move that worried many packet-radio 
experimenters, the FCC stated that “during the 
pendency of this proceeding there will be a 
moratorium on new repeater operation in Central 
Metropolitan Statistical Area6 and Metropolitan 
Statistical Areas.” These areas include many 
growing packet-radio networks. Packet-radio 
operators are asking whether this moratorium 
extends to simplex digipeater operation on 
previously established or coordinated frequencies. 
Informally, FCC officials have stated that packet 
radio is not covered by this repeater ban. While 
no formal determination has been made, it is clear 
that the FCC did not consider digipeaters before 
placing the 9-month ban on new repeater 
installations. 


On February 7, the ARRL filed a Petition for 
Partial Reconsideration, asking the FCC to drop 
the moratorium on new repeaters from NPRM 85-22. 
The ARRL sees both practical and legal problem6 
with the ban. Part of the Petition for Partial 
Reconsiderat ion reads: “the suggested moratorium 
comes at a very bad time in the evolution of 
packet-switching networks in the Amateur Radio 
Service which are dependent on repeaters for their 
operation. The suggested moratorium will place a 
chill on the development of packet repeaters and 
hence the communications experimentat ion which is 
presently at the forefront of amateur technology.” 
The FCC should consider this request soon. 


Comments on NPRM 85-22 must be filed by July 1, 
1985. Since the proposed rule changes would have 
some impact on frequency coordination for packet 
radio, packet operators should be sure to comment 
on the NPRM. 


Ed. 


NETWORK COORDINATION 


The recent FCC actions concerning repeater 
coordination underscore the need for packet-radio 
operator6 to work with local (and perhaps 
national) frequency-coordinating bodies. 


PACKET IN TEE PRESS 


The February issue of_The Institute, a publication 
of the Institute of Electrical and Electronics 
Engineers, contains an article titled “Hams 
Exploiting Packet Switching, Satellites, and 
More.” The article discusses the AX.25 standard, 
the uses of computers in amateur radio, and the 
growth of amateur packet radio. The author, Glenn 
Zorpette, interviewed both Paul Rinaldo, W4RI, and 
Jan King, W3GEY. Jan and Paul provided plenty of 


information to show the readers of The Institute 


that radio amateurs are still part of the state of 
the art. 


Ed. 
SEND IL!? YOUR PACKET NEWS 


When something happens in your packet-radio 
network, or you have an opinion on a Gateway item, 
send a note to_Gateway. Information is always 
worth more if it is made available to others. 


Ed. 
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the sunspots will be against us for at least the 
next three winters, and ve will need some 
mechanism for delivering the short-haul traffic. 


"We hope to use packet radio on VHF to deliver all 
of the traffic that we cannot deliver on HF. This 
should be accomplished using packet both within 
the Sixth Region and between the Sixth Region and 
other Regions. Since Oregon could provide liaison 
with the Seventh Region, ve would just need a link 
into the Twelfth Region (Arizona) to link all of 
the Pacific Area. A packet link into Arizona 
might be accomplished through Southern California. 


“We hope that, eventually,all NTS Section nets 
will establish liaison with a packet-radio 
network. On each packet-radio network there could 
be a “Section Net Mailbox" for outgoing and 
incoming messages. Some station would take the 
responsibility of passing traffic to and from the 
Section net everyday. 


“Eventually there will be enough satellite and HF 
links to permit each Section to send its traffic 
directly to the destination Section. In the 
meantime, we must use whatever links and routing 
mechanisms we have. 


"We would like to hear from any packet operators 
interested in establishing NTS mailboxes for their 
section. We are attempting to develop some 
software to facilitate NTS traffic handling. I 
have over 25 years experience with NTS, and I’m 
enthusiastic about the use of packet radio to 
provide efficient, 

communications." 


Write to: 


Don Simon, NI6A 

STM EAST BAY 

2327 Alva Ave. 

El Cerrito, CA 94539 


From NI6A. 


TCC SKEDS. 


Don Simon, NI6A, is looking for traffic operators 
to try making packet TCC schedules on OSCAR 19. 
TCC is the NIS Transcontinental Corps, who handle 
long-distance NTS traffic. Don can operate 126¢- 
bit/s, 19$@-Hz shift, or 369-bit/s, 20$-Hz shift. 
Interested TCC directors should contact Pat Berry, 
KN7B, TCC director for the Pacific Evening NTS. 


Via NI6A. 
UTAH PACKET-RADIO CLUB 


The Utah Packet Radio Association (UPRA) was 
formed on January 5, 1985, in Salt Lake City, 
Utah. 


UPRA was formed to _ meet several needs of the 
growing Packet-Radio Community in Utah, the most 
important of which is the development of packet 
radio in Utah. Other UPRA projects include the 
creation of a packet network between Salt Lake 
City and Denver and the development of links 
toward the Pacific Northwest and Southern 
California. 


Twenty interested hams, four of whom are already 
on packet, attended the first UFRA meeting. One 
of the charter members of UPRA is Rom Todd, KGER,, 
the ARBRE Utah Section Mamgger. 


For further information om UPEA, contact: 


David J. Pedersen, F7BEC 
President, Btah Packet Radio Assn. 
4382 Cherryview Drive 

West Valley City, UT 84129 


From UPRA. 


Jack Botner, VE3LNY, has deweloped 2 peripheral 
card for the IBM PC that uses an 8273 high lLewel 
data link controller (HDLC) integrated circwit to 
provide packet-radio 1/0 for the PC, The card 
allows the PC to access the HDLC chip through 
polling, interrupts or DMA. If you are an 
experimenter and you own an IBM PC, you will be 
interested in this project. Complete details, 
including a circuit diagram, appear in the 
January issue of QEX, the ARRL experimenter’s 
exchange. Although the article does not cover 
software to operate the controller, the AX.25 
software written by Phil Karn, KA9Q, could be 
modified to run on the PC. 


From QEX. 


12-¥ DC SUPPLY FOR TNCS 


——ae a 


Link Haymaker , K@2CO, and Tim Groat, KRG@U, from 
Colorado, have adapted an inexpensive ($4.95) 
surplus power supply board for use with the VADCG 
and TAPR TNCs. The supply is made by Iriichi 
Tsushin Kogyo Ltd., and is available from several 
sources, including Radio Shack and BNF 
Enterprises. The modifications to the supply will 
convert the negative 5-V output to negative 12-V 
(as required by the TNCs), and will allow the 
supply to operate with from1$V to 15 V de input. 
This allows the entize TNC to run from a 12-V 
battery, permitting portable and emergency 
operation, 


Some changes to the TAPR TNC are required, 
particularly on older pce boards. VADCG boards 
work without modification, since they were 
designed to use external power supplies. 


For a copy of the schematic and instructions for 
this conversion, send a business-sized §.a.s.e. 
with postage for 1 ounce to: 


Rocky Mountain Packet Radio Association 
Power Supply Exper iment s 

3775 W 115th Ave. 

Thornton, CO 80233. 


A power supply and a modified TAPR TNC will be 
available for inspection and demonstration at the 
TAPR Annual meeting. 


From N@CCcx. 


of the DCE proved to Conference attendees that 
low-cost satellites can provide reliable, 
worldwide, digital communication. AMSAT, VITA, 
and INTER-PARES hope that this presentation will 
create interest in and support for the PACSAT 
project. 


Via UoS, RK6K. 


PACKET RADIO IN THE ARRL HANDBOOK 

Packet-radio operators and experimenters, and 
those interested in digital communications will 
find a wealth of new information in the 1985 ARRL 
Handbook for the Radio Amateur. Extens ive 
editorial additions and revisions, coupled with 
several new projects have made the Handbook a 


state-of-the-art publication. 


For those who are new to computers and digital 
techniques, there is Chapter 8, “Digital Basics.” 
This chapter introduces digital logic, digital 
interfacing, and digital computers, among other 
topics. If you are looking for a guide to digital 
electronics, try “Digital Basics.” 


The “Digital Communications” chapter contains 3¢ 
pages of up-to-date information on digital 
techniques from Morse code to packet radio. 
Topics range from the RS-232-C interface standard 
to the OSI packet-switched network model. The 
chapter ends with a glossary of digital 
communications terms. 


Two of the projects in the “Digital Equipment” 
chapter should convince you to plug in your 
soldering iron. For troub leshoot ing serial 
interfaces, there is an RS-232-C breakout box. 
This piece of test equipment can save a lot of 
frustration when you are trying to hook a TNC to a 
computer or terminal. The other interesting 
project is a modem capable of using both Bell-202 
and Bell-103 tones. The modem has been used 
extensively on both HF and VHF packet. 


So, take a look at the 1985 ARRL Handbook-for the 
Radio Amateur. For $15.00, you get 1024 pages of 
useful radio and electronics information. 


Ed. 
TAPR MEETING 


Tucson Amateur Packet Radio Corp. (TAPR), will 
hold its annual meeting on Saturday, Fe-bruary 9, 
in the Granada Royale Hometel, Tucson, Arizona. 
If you can make it to Tucson, even if you are not 
a TAPR member, come to the meeting. This is a 
great opportunity to meet packet-radio operators 
from around the country, hear about growing 
packet-radio networks, and discuss the issues that 
face the packet community. 


Speakers at the meeting will include Steve Goode, 
KONG, and Harold Price, NK6K. Steve will describe 
his 969$9—bit/s, 228-MHz radios. His talk will end 
with a demonstration of high-speed packet radio-, 
Harold will talk about the successful UO-11 data 
communications experiment (DCE) test that were 
carried out in the end of January. Harold will 
probably touch on the status of PACSAT, too. TAPR 
is still lining up other speakers; expect to see 
many of the leaders in packet radio at the 


meeting. 


If you need further incentive to attend, there 
will be a free “packet pizza party” on Friday to 
kick off the meeting. 


The talk-in frequency will be 146.28/.88 MHz. 


Via WBSFLW. 


MIAMI PACKET FORUM 


There will be a Packet Radio Applications Forum at 
the Miami Hamcation on Sunday, February 3. This 
forum will feature Lyle J ohnson, WA7GXD, Pete 
Eaton, WB9FLW, and Paul Rinaldo, W4RI. These 
nationally recognized packet-radio experimenters 
will try to provide some answers to the question 
“what do we do with packet radio now that _ it’s 
here?” The forum is sponsored by the Florida 
Amateur Digital Communications Association 
(FADCA). For further information, contact J oel 
Kande 1 at (365)-596-9373. 


Via DR NET. 


PACKET BADIO DX CONTEST 


To prove that packet radio is “not just for 
computer hackers,” the Florida Amateur Digital 
Communications Association (FADCA) is sponsoring a 
packet-radio DX contest. All contacts must be 
made above 144 MHz. There is no limit to the 
number of digipeaters that can be used, but they 
must all be above 144 MHz. Satellite contacts are 
not allowed. Contacts must be in “real time;” 
that is, no store-and-forward mailboxes may be 
used. Distance will be measured between the 
endpoints of the contact, not along the route 
taken by the packets. A valid contact is the 
acknowledged exchange of name and QTH, in the 
connected mode. Contacts made between December 
31, 1984 and March 31, 1985. will count. All 
entries must be received by April 15. Send them 
to: 


Ted Huf, K4NTA 
1829 Pinetree Way 
Stuart, FL 33949. 


Have fun! 


From K4NTA. 


NTS TRAFFIC ON PACKET 


Gateway received the following letter from Don 
Simon, NI6A, East Bay Section Traffic Manager 
(STM): 


“While we are in the null of the sunspot cycle, 
band conditions on 8@-meter traffic nets will 
continue to get worse. Many ‘dyed-in-the-wool’ 
traffic handlers are attempting to use packet 
radio to help NTS move traffic around the country. 
Here on the Pacific West Coast, we hope to have 
packet links established north to the Oregon 
border and south to the Southern California 
Section Net before the next holiday-rush season. 
It may sound too early to plan for next winter, 
but to establish a reliable NTS packet network 
will take quite a bit of organization. Remember, 


Gateway 


The ARRL Packet-Radio Newsletter 


PROTOCOL SPECIFICATION AVAILABLE , 


In October 1984, the ARRL Board of Directors 
approved the AX.25 link-layer protocol presented 
to them by the ARRL Ad Hoc Committee On Amateur 
Radio Digital Communications. This protocol is 
the familiar AX.25, with a few small changes that 
were requested by packet-radio experimenters. 
Now, the protocol specification for AX.25, version 
2.0, is available from the ARRL. This is a formal 
protocol specification, providing all the 
informat ion necessary to implement AX.25. 


If you are building a TNC, of if you are simply 
interested in how your TNC works, you should get a 
copy of "AX.25 Amateur Packet-Radio Link-Layer 
Protocol.” The document is available from the 
ARRL for $8.00 in the U.S. and $9.06 in Canada and 
elsewhere. 


Do not be alarmed that this document is subtitled 
“Vers ion 2.9." The version number distinguishes 
this, the first official specification of AX.25, 
from previously available specifications. Version 
2.0 of AX.25 adopts the Poll/Final procedure 
proposed by Phil Karn, KA9Q. This procedure is 
compatible with existing implementat ions of AX.25. 


Vol. 1, No. 12 
Jan. 29, 1985 


The availability of a protocol specification for 
AK.25 opens the way for widespread standardization 
of amateur packet radio. Such standardization 
makes it possible for manufacturers to enter 
packet radio with confidence. It also makes 
international projects like JAS-1 and PACSAT more 
likely to be compatible with available TNCs. 


Congratulations to all of the experimenters, 
implementors, and operators who have made AK.25 a 
robust , mature protocol. 


Ed. 


DCE SUCCESS. 


Amateur radio operators affiliated with AMSAT, 
VITA, INTER-PARES, and the University of Surrey 
have successfully used the data communications 
experiment (DCE) aboard UoSAT-OSCAR-11 to exchange 
messages between Los Angeles, Hawaii, and the UK. 
On January 16, at the Pacific Telecommunications 
Conference in Honolulu, a portable station 
assembled by WH6AMX, WA3ZIA, and VE3FLL received 
messages that had been previously stored in the 
DCE by Harold Price, NK6K (in Los Angeles) and the 
UoSAT command station (in Surrey, England). 


The DCE was included on UO-11 to provide a “proof- 
of-concept“ experiment for worldwide, store-and- 
forward packet communications. Designed and built 
by AMSAT and Volunteers In Technical Assistance 
(VITA) teams from the U.S. and Canada, the DCE 
will evaluate the hardware, software and 
communications protocols that will be required for 
a fully operational packet satellite -- PACSAT. 


The DCE has been providing a “digital bypass” 
necessary to overcome communications problems that 
developed just after the launch of UO-11. In 
early January, G8NEF developed software that 
enabled the spacecraft’s primary computer to 
manage the “bypass ," making the DCE available for 
experiments. 


A Canadian group (headed by Larry Kayser, 
WA3ZIA/VE3), in conjunction with NK6K, developed a 
simple store-and-forward program for the DCE. The 
software was loaded into UQO-11 by NK6K, and the 
experiments were under way. 


WA3ZIA and Lionel Pett, VE3FLL, attended the 
Pac if ic Telecommunications Conference to discuss 
the potential uses of PACSAT. They enlisted Rick 
Dittmer, WH6AMX to help them assemble and operate 
a portable ground station at the Conference. 
Despite poor weather, the team was able to receive 
messages from the DCE and copy the UO-9 “Special 
Events Bulletin.” This successful demonstration 


SOFTNETWORKSHOP 


The SOFTNET User’s Group (SUG), in cooperat ion 
with Linkoping University, will hold its third 
SOFTNET Workshop on Sunday May 11, 1985, at 
Linkoping University, Linkoping, Sweden. 
Technical papers are solicited on high-speed 
packet-radio hardware and propagation, distributed 
routing in packet-radio networks, SOFTNET 
applications, and SOFTNET specification issues. 
Camera-ready summaries consisting of less than two 
standard A4 pages should be received by SUG by MAY 
Ist. Proceedings from the workshop will be 
available through SUG. For more information 
contact: 


Per Lundgren 

SUG, Department of Electrical Engineering 
Linkoping University 

S-581 83, Linkoping 

SWEDEN. 


From Softaet News. 
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with the higher and iower echelons of NTS. 


“Points 3 and 4 are the real stumbling blocks for 
a packet net. Regular interfacing to NTSis a 
chore! Stations must be available at prescribed 
times on a reliable, regular basis in order for 
the traffic flow to be effected properly. 


“None of the above is to insinuate that a packet 
network cannot become officially affiliated with 
NTS. I just wanted to point out that a monthly 
net report is NOT the sole criterion for NTS 
affiliation.” 


From WA4STO. 


DIGITAL COMMUNICATIONS BOOK 


Gateway received the following book review from 
Pete Eaton, WB9FLW: 


“While browsing through the bargin table at the 
local Radio Shack, I happened to glance at their 
rack of tutorial books. To my suprise, one of the 
t it les was Understand ing Data Communications. For 
the last several years, newcomers to packet radio 
have been asking for some introductory reference 
material written in plain language. Understand_ing 
Data Communications, developed and published by 
the Texas Instruments Learning Center, comes close 
to filling the bill. 


“Each chapter introduces you to a fundamental 
concept in digital communications. Topics covered 
include an overview of data communications, data 
terminals, types of messages and transmission 
channels, asynchronous and synchronous operation, 
and satel lite commun icat ions. 

“Of special interest to amateur packet operators 
are chapters covering ‘Protocols and Error 
Control,’ ‘Local Area Networks,’ and ‘Network 
Design and Management.’ A special treat is 
Chapter 9, ‘Architecture and Packet Networks,’ 
which uses X.25 as an example of a packet- 
switching network protocol. 


“The whole book is written in clear, down-to-earth 
language. Once a novice has read all the 
chapters, I’m sure that he will better understand 
and appreciate the potential of Packet Radio in 
the Amateur Radio Service. If you are getting 
confused by all the talk of ‘protocols,’ “LANs,” 
“FSK,° “PSK,” and ‘level 38,’ give yourself a 
present from Radio Shack.” 


[Remember that a thorough introduct ion to packet 
radio and several projects of interest to packet 
operators appear in the 1985 edition of The ARRL 
Handbook-for the Radia Amateur. -- Ed.] 


From WB9FLW. 


PACKET RADIO_IN JAPAN 


Us ing a TAPR TNC as a debugging aid and 
compatibility tester, several Japanese amateurs 
are implementing their own TNC. The TNC will use 
a 289 CPU and an 8273 HDLC chip. JAIMIR reports 
that JIJBXM is writing the AX.25 software for the 
TNC and that it should be complete by the end of 
January. 


The Japanese group will be building an OSCAR 19 


Stat ion .. cermunicate with U.S. ‘packet 
exper imenters. They are particularly interested 
in internetwork (level-3) protocol development and 
high-speed modem research. Look for them on the 
satellite. 


Takemi, JAIMIR, notes: “Designing our own TNC 
through understanding the AX.25 specification is 
great fun. I haven’t been involved in such an 
exciting amateur-radio project for more than 1¢ 
years !" 


Via NK6K. 


PACKET RADIO IN ENGLAND 


The following report on packet-rad io activity in 
England was sent to us by Reg Brake, G8QR: 


“In Norwich, there are now five stations equipped 
with TAPR TNCs. Those stations are G3LDI, G3PMQ, 
G4RSP, G6JTH, and myself. In addition, there are 
about fifteen local stations equipped with the 
software packet-radio program that runs on the BBC 
microcomputer. This program was developed by 
G6GIX and G8WJL at the Cambridge University 
Computer Laboratory. 


“All of the stations equipped with TAPR boards 
have worked successfully on VHF. G3PMQ and I have 
also made contact with Ipswich. This activity is 
on 144.68 MHz, using 129@ bauds, 1¢¢@-Hz shift. 
In the last month, however, we have modified the 
TAPR boards to switch from wide shift to narrow 
shift at the touch of a button. The phys ica 1 
arrangement for this was designed by G6JTH and it 
functions very well. Since that time, we have 
been doing some HF packet operation. 


“On 14.193 MHz, we made the first England-to- 
Germany packet-radio QSO, with DL2MDE. As I speak 
German, I initiated the contact, but both G3PMQ 
and I maintained an hour-long QSO with solid copy 
both ways. We have heard the American packet 
station [W@RLI] at 14.986 MHz, but signals were 
weak at the time, and we were not equipped with a 
tuning indicator. Since then, two stations have 
built the TAPR LED tuning indicator and use this 
very successfully on HF. We are looking for 
contacts on 14 MHz, although we are uncertain of 
the preferred frequencies. None of us is yet on 
OSCAR 19, so we are anxious for contacts on HF.” 


The winter copy of DATACQOM, the journal of the 
British Amateur Radio Teleprinter Group (BARTG) 
contains a packet-radio column by Ian Wade G8NRW. 
In that column, Ian provides a list of about 64 
stations active on packet radio in England. 


If you are going to be in England this spring, 
note the following (also from BARTG DATACOM): At 
the RSGB VHF Convention at Sandown Park on March 
23, 1985, Ian Wade, of BARTG, is presenting a talk 
entitled “How Packet Radio Works.” For more 
informat ion contact 


Ian Wade, G8NRW 

7 Daubeney Close 
Har 1 ing ton, DUNSTABI.E 
Bedfordshire, LU5 6NF 
ENGLAND. 


From G8QR and DATACOM 


discussion of how present TNCs handle retries and 
of a couple of bugs in the TAPR TNC-1 software 
(version 3.3) that add to network congestion. 


There are now three UNIX nodes known to be 
operating on EASTNET. They are run by Phil Karn, 
Jim Kutsch, KY2D, and Brian Lloyd. Brian gave 
details on how to get USENET mail onto EASTNET 
through these systems. 


Via HAMNET. 


SOUTHNET XI UPDATE 


We have received further details on the SOUTHNET 
II conference to be held at Georgia Tech, on 
November 23 and 24. The featured presentations 
are: 


o Lyle Johnson, WA7GXD, and Pete Eaton, WB9FLW, 
on the TAPR Network Node Controller. 


o Ed Jackson, WB20IF, from GLB, will discuss the 
AX.25 protocol, the PK-l1 command set and 
future GLB projects. 


o Demonstrations of all available packet 
hardware. 


o  SOUTHNET organizational meeting. 


o SOUTHNET awards, including the "SOUTHNET 
Packeteer of the Year.’ 


Technical sessions will include a report on the 
progress of digipeaters in the SOUTHNET region, an 
update on the 9600-baud modem, a status report on 
220-MHz linking, discussions of various networking 
proposals, sessions covering the W#RLI Gateway and 
MailBox, and a roundup of Xerox 820 information. 
There will also be an introductory presentation 
for those just getting started or interested in 
packet radio. The conference will be capped by a 
banquet on Saturday evening. 


Members of GRAPES, the Georgia Radio Amateur 
Packet Enthusiasts Society, will provide 
transportation to and from the airport. Those 
that need this service should contact Bill Crews, 
WB2CPV, at least 3 weeks prior to the conference. 
With super-saver air fares available, you should 
prepare early to attend SOUTHNET II. 


There will be a final mailing of conference 
information in early November, including a 
complete agenda, maps of the meeting location and 
information on sightseeing in Atlanta. To get 
this information, send an SASE to 


Bill Crews, WB2CPV 
1421 Hampton Ridge Road 
Norcross, GA 30093. 


Via DRENET. 


CENTER FOR WORLI ROUTING INFORMATION? 


With new WO@RLI MailBox and Gateway stations coming 
on the air frequently, it is hard for sysops 
(system operators) to keep track of all of the 
interconnected PBBSs. In order for the system to 
work, each PBBS must know which of its neighbors 
to send mail to for every PBBS in the network. 


While it is not practical to keep track of all 
PBBS users and their whereabouts, it is a smaller 
task to keep track of each PBBS and the paths 
through which it can be accessed. David Dodell, 
WB7TPY, has suggested that someone maintain a 
database of MailBoxes and Gateways, allowing 
sysops to get timely information about new systems 
and paths. If you have any comments about this, 
send them via packet to WB7TPY @ K7PYK or put them 
in the mail to Gateway. 


Via HAMNET. 


SOUTH TEXAS PACKET 


The Texas Tech University Amateur Radio Club will 
be putting up several new repeaters this fall. 
One of the machines will be a packet-radio 
digipeater on 145.01 MHz. Ronald Cole, N5HYH, is 
in charge of the club’s station operations, and he 
is planning to put a packet-radio bulletin board 
system (PBBS) on the air to stir up some local 
interest in packet. The other repeaters to be 
installed by the Texas Tech club include a duplex 
repeater dedicated to experimental modes (on 
147.38/.98 MHz) and a machine on the new 902-MHz 
band, 


Via HAMNET. 


SCANNING DIGIPEATER 


In a message from W6CUS-1 PBBS that was posted on 
CompuServe HAMNET, Don Simon, NI6A, reports that 
there is now a scanning digipeater serving the San 
Francisco area. The digipeater, N61JP-l, is 
located about 2000 feet above the city of Angwin, 
California. It scans all packet frequencies 
between 145.10 MHz and 145.09 MHz, stopping for 
six seconds on each frequency. Once it has been 
accessed on a given channel, the digipeater stays 
on that channel until it has not been accessed for 
two minutes. If your group would like to have a 
digipeater that serves occasional contacts on 
several frequencies, this scheme may be the way to 
go. For further details on how the scanning 
digipeater is implemented, contact 


Randy Fischer, N6IJP 
455 Bay Street 
Angwin, CA 94508. 


Via HAMNET. 


HF GATEWAY IN COLORADO 


Dave Shavey, KQHOA, now has an HF gateway 
operating in Colorado Springs, Colorado. Dave is 
using the W@RLI Gateway software, and provides 
full service, including message forwarding, 24 
hours a day. Like most of the other HF gateways, 
KHOA is on 14.103 MHz. 


We hear that the midwest jis not far behind, with 
the crew at WB9FLW in St. Louis, Missouri, moving 
quickly to get a W@RLI Gateway and MailBox on the 
air. 


Via N§CCZ, DRNET. 


NEW CALIFORNIA DIGIPEATER 


A new digipeater in northern California, WA6YNG-1, 
should provide communications between southern 
Oregon and Sacramento. The digipeater was 
installed in the Mt. Shasta area, at an elevation 
of 7000 feet. Both county and state Offices of 
Emergency Services cooperated to make this high- 
altitude site available. Operating on 145.01 MHz, 
WA6YNG-1 can be reached through W6AMT-7. 


Via HAMNET. 


ST. LOUIS MOVES TO 145.01 MHZ 


The St. Louis Amateur Packet Radio Club (SLAPR) is 
moving its packet operation from 147.555 MHZ to 
145.01 MHz. This change has been coordinated in 
Eastern Missouri and Southern Illinois. Our 
coordination agreement states that the move will 
be complete by October 15th. 


Via WB9FLW, DRNET. 
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